Re: [FFmpeg-devel] [PATCH] avformat/mxfdec: signal channel layouts using the new channel layout api
Quoting Marton Balint (2024-03-08 21:13:59) > +ret = av_channel_layout_retype(ch_layout, AV_CHANNEL_ORDER_NATIVE, > AV_CHANNEL_LAYOUT_RETYPE_FLAG_LOSSLESS); > +if (ret == AVERROR(ENOSYS)) > +ret = av_channel_layout_retype(ch_layout, AV_CHANNEL_ORDER_UNSPEC, > AV_CHANNEL_LAYOUT_RETYPE_FLAG_LOSSLESS); It might be useful to have an av_channel_layout_retype() flag (something like AV_CHANNEL_LAYOUT_RETYPE_FLAG_CANONICALISE) that converts to the simplest possible representation (not saying you need to add it right now, it's just a note for future consideration). -- Anton Khirnov ___ 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".
Re: [FFmpeg-devel] [PATCH] avformat/mxfdec: signal channel layouts using the new channel layout api
On Fri, 8 Mar 2024, James Almer wrote: On 3/8/2024 5:13 PM, Marton Balint wrote: Signed-off-by: Marton Balint --- libavformat/mxfdec.c | 129 ++- 1 file changed, 53 insertions(+), 76 deletions(-) diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c index 289db9833c..e2f4a22983 100644 --- a/libavformat/mxfdec.c +++ b/libavformat/mxfdec.c [...] +ret = av_channel_layout_retype(ch_layout, AV_CHANNEL_ORDER_NATIVE, AV_CHANNEL_LAYOUT_RETYPE_FLAG_LOSSLESS); +if (ret == AVERROR(ENOSYS)) +ret = av_channel_layout_retype(ch_layout, AV_CHANNEL_ORDER_UNSPEC, AV_CHANNEL_LAYOUT_RETYPE_FLAG_LOSSLESS); +if (ret < 0 && ret != AVERROR(ENOSYS)) +return ret; return 0; } I'm not against this patch, but shouldn't we make sure for example that swr supports custom layouts first? I don't really know what is the best approach here. Sure, some stuff will break if it encounters a custom layout. But nobody will fix it, if no custom layouts are ever encountered... Regards, Marton ___ 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".
[FFmpeg-devel] [PATCH] doc/examples/qsv_decode.c: remove unused config.h header file
Signed-off-by: clarkh mailto:hungkuish...@outlook.com>> --- doc/examples/qsv_decode.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/doc/examples/qsv_decode.c b/doc/examples/qsv_decode.c index cc2662d5bd..901eac3b27 100644 --- a/doc/examples/qsv_decode.c +++ b/doc/examples/qsv_decode.c @@ -28,8 +28,6 @@ * GPU video surfaces, write the decoded frames to an output file. */ -#include "config.h" - #include #include "libavformat/avformat.h" -- 2.34.1 ___ 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".
Re: [FFmpeg-devel] Did FATE have an unhappy accident?
On Fri, Mar 08, 2024 at 10:17:04AM -0500, Sean McGovern wrote: > It's been unreachable since yesterday. fixed by baptsite some issue related to maintaince that left disk mounted read only thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB He who knows, does not speak. He who speaks, does not know. -- Lao Tsu signature.asc Description: PGP signature ___ 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".
Re: [FFmpeg-devel] [PATCH] avfilter/fifo: Remove (a)fifo filters
On Fri, Mar 8, 2024 at 10:30 PM Paul B Mahol wrote: > On Fri, Mar 8, 2024 at 4:18 PM Muhammad Faiz wrote: > > > On Fri, Mar 8, 2024 at 5:40 PM Andreas Rheinhardt < > > andreas.rheinha...@outlook.com> wrote: > > > > > Muhammad Faiz: > > > > On Tue, Feb 6, 2024 at 3:58 PM Andreas Rheinhardt < > > > > andreas.rheinha...@outlook.com> wrote: > > > > > > > >> Andreas Rheinhardt: > > > >>> Obsolete since 4ca1fb9d2a91757c8c4c34dd456abf340e3f765f. > > > >>> > > > >>> Signed-off-by: Andreas Rheinhardt > > > >>> --- > > > >>> doc/filters.texi | 9 --- > > > >>> libavfilter/Makefile | 1 - > > > >>> libavfilter/allfilters.c | 2 - > > > >>> libavfilter/fifo.c | 165 > > --- > > > >>> 4 files changed, 177 deletions(-) > > > >>> delete mode 100644 libavfilter/fifo.c > > > >>> > > > >> > > > >> Will apply in a few days unless there are objections. > > > >> > > > >> - Andreas > > > >> > > > >> > > > > This breaks backward compatibility. > > > > > > > > Please revert. > > > > > > > > Thank's. > > > > > > What breaks that can't simply be fixed by removing the (a)fifo filter > > > from the filterchain? > > > > > > - Andreas > > > > > > > > I use afifo to optimize memory usage. > > > > That statement sync with reality is questionable, fifo filters were mainly > used before .activate was added, > for cases filters used >1 inputs. Now they should be irrelevant, unless > there are bugs in code than this filters just hide more bugs. > Yes, I've used it before .activate was added, and it worked, and still works. Although maybe the bugs have been fixed by .activate, what's wrong if (a)fifo still exist? Thank's ___ 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".
Re: [FFmpeg-devel] [PATCH] avfilter/fifo: Remove (a)fifo filters
On Fri, Mar 8, 2024 at 10:46 PM Andreas Rheinhardt < andreas.rheinha...@outlook.com> wrote: > Muhammad Faiz: > > On Fri, Mar 8, 2024 at 5:40 PM Andreas Rheinhardt < > > andreas.rheinha...@outlook.com> wrote: > > > >> Muhammad Faiz: > >>> On Tue, Feb 6, 2024 at 3:58 PM Andreas Rheinhardt < > >>> andreas.rheinha...@outlook.com> wrote: > >>> > Andreas Rheinhardt: > > Obsolete since 4ca1fb9d2a91757c8c4c34dd456abf340e3f765f. > > > > Signed-off-by: Andreas Rheinhardt > > --- > > doc/filters.texi | 9 --- > > libavfilter/Makefile | 1 - > > libavfilter/allfilters.c | 2 - > > libavfilter/fifo.c | 165 > --- > > 4 files changed, 177 deletions(-) > > delete mode 100644 libavfilter/fifo.c > > > > Will apply in a few days unless there are objections. > > - Andreas > > > >>> This breaks backward compatibility. > >>> > >>> Please revert. > >>> > >>> Thank's. > >> > >> What breaks that can't simply be fixed by removing the (a)fifo filter > >> from the filterchain? > >> > >> - Andreas > >> > >> > > I use afifo to optimize memory usage. > > And backward incompatible change should only be allowed with deprecation > > periods and major version bump. > > > > Deprecation periods etc. are only common for API breaks; we do not > guarantee that any particular filter etc. stays available and therefore > occasionally remove them without deprecation. Examples of this are the > removal of libopenjpeg in 60ccb3fe787, the removal of libwavpackenc in > 45070eec4c or the removal of the XvMC hardware acceleration in > be95df12bb06 (the last commit was accompanied by cefa595361db9 and > b648ece34b6f which deprecated the parts of XvMC that were part of the > public API and therefore subject to the API stability contract). > > - Andreas > > It seems that all of them are external dependent components. So, I think that non external dependent components should be treated differently. Also, what is the urgency of (a)fifo removal? Thank's ___ 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".
Re: [FFmpeg-devel] [PATCH] avformat/mxfdec: signal channel layouts using the new channel layout api
On 3/8/2024 5:13 PM, Marton Balint wrote:
Signed-off-by: Marton Balint
---
libavformat/mxfdec.c | 129 ++-
1 file changed, 53 insertions(+), 76 deletions(-)
diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c
index 289db9833c..e2f4a22983 100644
--- a/libavformat/mxfdec.c
+++ b/libavformat/mxfdec.c
@@ -188,8 +188,6 @@ typedef struct {
int body_sid;
MXFWrappingScheme wrapping;
int edit_units_per_packet; /* how many edit units to read at a time (PCM,
ClipWrapped) */
-int require_reordering;
-int channel_ordering[FF_SANE_NB_CHANNELS];
} MXFTrack;
typedef struct MXFDescriptor {
@@ -1652,48 +1650,48 @@ static const MXFCodecUL
mxf_data_essence_container_uls[] = {
typedef struct MXFChannelOrderingUL {
UID uid;
-uint64_t layout_mask;
+enum AVChannel channel;
enum AVAudioServiceType service_type;
} MXFChannelOrderingUL;
static const MXFChannelOrderingUL mxf_channel_ordering[] = {
-{ {
0x06,0x0e,0x2b,0x34,0x04,0x01,0x01,0x0d,0x03,0x02,0x01,0x01,0x00,0x00,0x00,0x00
}, AV_CH_FRONT_LEFT,AV_AUDIO_SERVICE_TYPE_MAIN }, // Left
-{ {
0x06,0x0e,0x2b,0x34,0x04,0x01,0x01,0x0d,0x03,0x02,0x01,0x02,0x00,0x00,0x00,0x00
}, AV_CH_FRONT_RIGHT, AV_AUDIO_SERVICE_TYPE_MAIN }, // Right
-{ {
0x06,0x0e,0x2b,0x34,0x04,0x01,0x01,0x0d,0x03,0x02,0x01,0x03,0x00,0x00,0x00,0x00
}, AV_CH_FRONT_CENTER, AV_AUDIO_SERVICE_TYPE_MAIN }, // Center
-{ {
0x06,0x0e,0x2b,0x34,0x04,0x01,0x01,0x0d,0x03,0x02,0x01,0x04,0x00,0x00,0x00,0x00
}, AV_CH_LOW_FREQUENCY, AV_AUDIO_SERVICE_TYPE_MAIN }, // Low Frequency
Effects
-{ {
0x06,0x0e,0x2b,0x34,0x04,0x01,0x01,0x0d,0x03,0x02,0x01,0x05,0x00,0x00,0x00,0x00
}, AV_CH_SIDE_LEFT, AV_AUDIO_SERVICE_TYPE_MAIN }, // Left Surround
-{ {
0x06,0x0e,0x2b,0x34,0x04,0x01,0x01,0x0d,0x03,0x02,0x01,0x06,0x00,0x00,0x00,0x00
}, AV_CH_SIDE_RIGHT,AV_AUDIO_SERVICE_TYPE_MAIN }, // Right Surround
-{ {
0x06,0x0e,0x2b,0x34,0x04,0x01,0x01,0x0d,0x03,0x02,0x01,0x07,0x00,0x00,0x00,0x00
}, AV_CH_SIDE_LEFT, AV_AUDIO_SERVICE_TYPE_MAIN }, // Left Side
Surround
-{ {
0x06,0x0e,0x2b,0x34,0x04,0x01,0x01,0x0d,0x03,0x02,0x01,0x08,0x00,0x00,0x00,0x00
}, AV_CH_SIDE_RIGHT,AV_AUDIO_SERVICE_TYPE_MAIN }, // Right Side
Surround
-{ {
0x06,0x0e,0x2b,0x34,0x04,0x01,0x01,0x0d,0x03,0x02,0x01,0x09,0x00,0x00,0x00,0x00
}, AV_CH_BACK_LEFT, AV_AUDIO_SERVICE_TYPE_MAIN }, // Left Rear
Surround
-{ {
0x06,0x0e,0x2b,0x34,0x04,0x01,0x01,0x0d,0x03,0x02,0x01,0x0a,0x00,0x00,0x00,0x00
}, AV_CH_BACK_RIGHT,AV_AUDIO_SERVICE_TYPE_MAIN }, // Right Rear
Surround
-{ {
0x06,0x0e,0x2b,0x34,0x04,0x01,0x01,0x0d,0x03,0x02,0x01,0x0b,0x00,0x00,0x00,0x00
}, AV_CH_FRONT_LEFT_OF_CENTER, AV_AUDIO_SERVICE_TYPE_MAIN }, // Left Center
-{ {
0x06,0x0e,0x2b,0x34,0x04,0x01,0x01,0x0d,0x03,0x02,0x01,0x0c,0x00,0x00,0x00,0x00
}, AV_CH_FRONT_RIGHT_OF_CENTER, AV_AUDIO_SERVICE_TYPE_MAIN }, // Right Center
-{ {
0x06,0x0e,0x2b,0x34,0x04,0x01,0x01,0x0d,0x03,0x02,0x01,0x0d,0x00,0x00,0x00,0x00
}, AV_CH_BACK_CENTER, AV_AUDIO_SERVICE_TYPE_MAIN }, // Center Surround
-{ {
0x06,0x0e,0x2b,0x34,0x04,0x01,0x01,0x0d,0x03,0x02,0x01,0x0e,0x00,0x00,0x00,0x00
}, AV_CH_FRONT_CENTER, AV_AUDIO_SERVICE_TYPE_VISUALLY_IMPAIRED }, //
Hearing impaired audio channel
-{ {
0x06,0x0e,0x2b,0x34,0x04,0x01,0x01,0x0d,0x03,0x02,0x01,0x0f,0x00,0x00,0x00,0x00
}, AV_CH_FRONT_CENTER, AV_AUDIO_SERVICE_TYPE_HEARING_IMPAIRED }, //
Visually impaired narrative audio channel
-{ {
0x06,0x0e,0x2b,0x34,0x04,0x01,0x01,0x0d,0x03,0x02,0x01,0x20,0x03,0x00,0x00,0x00
}, AV_CH_STEREO_LEFT, AV_AUDIO_SERVICE_TYPE_MAIN }, // Left Total
-{ {
0x06,0x0e,0x2b,0x34,0x04,0x01,0x01,0x0d,0x03,0x02,0x01,0x20,0x04,0x00,0x00,0x00
}, AV_CH_STEREO_RIGHT, AV_AUDIO_SERVICE_TYPE_MAIN }, // Right Total
-{ {
0x06,0x0e,0x2b,0x34,0x04,0x01,0x01,0x0d,0x03,0x02,0x01,0x30,0x01,0x01,0x00,0x00
}, AV_CH_TOP_FRONT_LEFT,AV_AUDIO_SERVICE_TYPE_MAIN }, // Left Height
-{ {
0x06,0x0e,0x2b,0x34,0x04,0x01,0x01,0x0d,0x03,0x02,0x01,0x30,0x01,0x02,0x00,0x00
}, AV_CH_TOP_FRONT_RIGHT, AV_AUDIO_SERVICE_TYPE_MAIN }, // Right Height
-{ {
0x06,0x0e,0x2b,0x34,0x04,0x01,0x01,0x0d,0x03,0x02,0x01,0x30,0x01,0x03,0x00,0x00
}, AV_CH_TOP_FRONT_CENTER, AV_AUDIO_SERVICE_TYPE_MAIN }, // Center Height
-{ {
0x06,0x0e,0x2b,0x34,0x04,0x01,0x01,0x0d,0x03,0x02,0x01,0x30,0x01,0x04,0x00,0x00
}, AV_CH_TOP_SIDE_LEFT, AV_AUDIO_SERVICE_TYPE_MAIN }, // Left Surround
Height
-{ {
0x06,0x0e,0x2b,0x34,0x04,0x01,0x01,0x0d,0x03,0x02,0x01,0x30,0x01,0x05,0x00,0x00
}, AV_CH_TOP_SIDE_RIGHT,AV_AUDIO_SERVICE_TYPE_MAIN }, // Right Surround
Height
-{ {
0x06,0x0e,0x2b,0x34,0x04,0x01,0x01,0x0d,0x03,0x02,0x01,0x30,0x01,0x06,0x00,0x00
}, AV_CH_TOP_SIDE_LEFT, AV_AUDIO_SERVICE_TYPE_MAIN }, // Left
[FFmpeg-devel] [PATCH 2/2 v2] fftools/ffprobe: export IAMF Stream Group parameters
Signed-off-by: James Almer
---
doc/ffprobe.xsd | 39 ++
fftools/ffprobe.c | 160 +++-
tests/fate/iamf.mak | 12 +-
tests/fate/mov.mak | 8 +-
tests/ref/fate/iamf-5_1_4 | 92 ++
tests/ref/fate/iamf-7_1_4 | 92 ++
tests/ref/fate/iamf-ambisonic_1 | 39 ++
tests/ref/fate/iamf-stereo | 67 ++
tests/ref/fate/mov-mp4-iamf-5_1_4 | 92 ++
tests/ref/fate/mov-mp4-iamf-7_1_4 | 92 ++
tests/ref/fate/mov-mp4-iamf-ambisonic_1 | 39 ++
tests/ref/fate/mov-mp4-iamf-stereo | 67 ++
12 files changed, 787 insertions(+), 12 deletions(-)
diff --git a/doc/ffprobe.xsd b/doc/ffprobe.xsd
index bd52000725..6d5d094d97 100644
--- a/doc/ffprobe.xsd
+++ b/doc/ffprobe.xsd
@@ -366,10 +366,49 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/fftools/ffprobe.c b/fftools/ffprobe.c
index bf635ffbd6..58fb5427b1 100644
--- a/fftools/ffprobe.c
+++ b/fftools/ffprobe.c
@@ -42,6 +42,7 @@
#include "libavutil/film_grain_params.h"
#include "libavutil/hash.h"
#include "libavutil/hdr_dynamic_metadata.h"
+#include "libavutil/iamf.h"
#include "libavutil/mastering_display_metadata.h"
#include "libavutil/hdr_dynamic_vivid_metadata.h"
#include "libavutil/dovi_meta.h"
@@ -215,6 +216,12 @@ typedef enum {
SECTION_ID_STREAM_GROUP_COMPONENT,
SECTION_ID_STREAM_GROUP_SUBCOMPONENTS,
SECTION_ID_STREAM_GROUP_SUBCOMPONENT,
+SECTION_ID_STREAM_GROUP_PIECES,
+SECTION_ID_STREAM_GROUP_PIECE,
+SECTION_ID_STREAM_GROUP_SUBPIECES,
+SECTION_ID_STREAM_GROUP_SUBPIECE,
+SECTION_ID_STREAM_GROUP_BLOCKS,
+SECTION_ID_STREAM_GROUP_BLOCK,
SECTION_ID_STREAM_GROUP_STREAMS,
SECTION_ID_STREAM_GROUP_STREAM,
SECTION_ID_STREAM_GROUP_DISPOSITION,
@@ -288,8 +295,8 @@ static struct section sections[] = {
[SECTION_ID_FRAME_SIDE_DATA_TIMECODE] = {
SECTION_ID_FRAME_SIDE_DATA_TIMECODE, "timecode", 0, { -1 } },
[SECTION_ID_FRAME_SIDE_DATA_COMPONENT_LIST] = {
SECTION_ID_FRAME_SIDE_DATA_COMPONENT_LIST, "components", SECTION_FLAG_IS_ARRAY,
{ SECTION_ID_FRAME_SIDE_DATA_COMPONENT, -1 }, .element_name = "component",
.unique_name = "frame_side_data_components" },
[SECTION_ID_FRAME_SIDE_DATA_COMPONENT] = {
SECTION_ID_FRAME_SIDE_DATA_COMPONENT, "component",
SECTION_FLAG_HAS_VARIABLE_FIELDS|SECTION_FLAG_HAS_TYPE, {
SECTION_ID_FRAME_SIDE_DATA_PIECE_LIST, -1 }, .unique_name =
"frame_side_data_component", .element_name = "component_entry", .get_type =
get_raw_string_type },
-[SECTION_ID_FRAME_SIDE_DATA_PIECE_LIST] = {
SECTION_ID_FRAME_SIDE_DATA_PIECE_LIST, "pieces", SECTION_FLAG_IS_ARRAY, {
SECTION_ID_FRAME_SIDE_DATA_PIECE, -1 }, .element_name = "piece" },
-[SECTION_ID_FRAME_SIDE_DATA_PIECE] ={
SECTION_ID_FRAME_SIDE_DATA_PIECE, "piece",
SECTION_FLAG_HAS_VARIABLE_FIELDS|SECTION_FLAG_HAS_TYPE, { -1 }, .element_name =
"piece_entry", .get_type = get_raw_string_type },
+[SECTION_ID_FRAME_SIDE_DATA_PIECE_LIST] = {
SECTION_ID_FRAME_SIDE_DATA_PIECE_LIST, "pieces", SECTION_FLAG_IS_ARRAY, {
SECTION_ID_FRAME_SIDE_DATA_PIECE, -1 }, .element_name = "piece", .unique_name =
"frame_side_data_pieces" },
+[SECTION_ID_FRAME_SIDE_DATA_PIECE] ={
SECTION_ID_FRAME_SIDE_DATA_PIECE, "piece",
SECTION_FLAG_HAS_VARIABLE_FIELDS|SECTION_FLAG_HAS_TYPE, { -1 }, .element_name =
"piece_entry", .unique_name = "frame_side_data_piece", .get_type =
get_raw_string_type },
[SECTION_ID_FRAME_LOGS] = { SECTION_ID_FRAME_LOGS, "logs",
SECTION_FLAG_IS_ARRAY, { SECTION_ID_FRAME_LOG, -1 } },
[SECTION_ID_FRAME_LOG] = { SECTION_ID_FRAME_LOG, "log", 0, { -1
}, },
[SECTION_ID_LIBRARY_VERSIONS] = { SECTION_ID_LIBRARY_VERSIONS,
"library_versions", SECTION_FLAG_IS_ARRAY, { SECTION_ID_LIBRARY_VERSION, -1 } },
@@ -319,7 +326,13 @@ static struct section sections[] = {
[SECTION_ID_STREAM_GROUP_COMPONENTS] = {
SECTION_ID_STREAM_GROUP_COMPONENTS, "components", SECTION_FLAG_IS_ARRAY, {
SECTION_ID_STREAM_GROUP_COMPONENT, -1 }, .element_name = "component",
.unique_name = "stream_group_components" },
[SECTION_ID_STREAM_GROUP_COMPONENT] = {
SECTION_ID_STREAM_GROUP_COMPONENT, "component",
SECTION_FLAG_HAS_VARIABLE_FIELDS|SECTION_FLAG_HAS_TYPE, {
SECTION_ID_STREAM_GROUP_SUBCOMPONENTS, -1 }, .unique_name =
"stream_group_component", .element_name = "component_entry", .get_type =
get_stream_group_type },
[SECTION_ID_STREAM_GROUP_SUBCOMPONENTS] = {
SECTION_ID_STREAM_GROUP_SUBCOMPONENTS, "subcomponents", SECTION_FLAG_IS_ARRAY,
{ SECTION_ID_STREAM_GROUP_SUBCOMPONENT, -1 }, .element_name =
[FFmpeg-devel] [PATCH 1/2 v3] fftools/ffprobe: export Tile Grid Stream Group parameters
Signed-off-by: James Almer
---
doc/ffprobe.xsd | 50 +
fftools/ffprobe.c | 53 ---
tests/fate/mov.mak| 6 +--
.../ref/fate/mov-heic-demux-still-image-grid | 29 ++
.../ref/fate/mov-heic-demux-still-image-iovl | 19 +++
.../fate/mov-heic-demux-still-image-iovl-2| 19 +++
6 files changed, 165 insertions(+), 11 deletions(-)
I'll factorize the tests arguments later.
diff --git a/doc/ffprobe.xsd b/doc/ffprobe.xsd
index 5010c5a45f..bd52000725 100644
--- a/doc/ffprobe.xsd
+++ b/doc/ffprobe.xsd
@@ -15,6 +15,7 @@
+
@@ -229,6 +230,12 @@
+
+
+
+
+
+
@@ -325,6 +332,49 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/fftools/ffprobe.c b/fftools/ffprobe.c
index e003ac6cfd..bf635ffbd6 100644
--- a/fftools/ffprobe.c
+++ b/fftools/ffprobe.c
@@ -114,6 +114,7 @@ static int do_show_frames = 0;
static int do_show_packets = 0;
static int do_show_programs = 0;
static int do_show_stream_groups = 0;
+static int do_show_stream_group_components = 0;
static int do_show_streams = 0;
static int do_show_stream_disposition = 0;
static int do_show_stream_group_disposition = 0;
@@ -210,6 +211,10 @@ typedef enum {
SECTION_ID_STREAM_GROUP_STREAM_DISPOSITION,
SECTION_ID_STREAM_GROUP_STREAM_TAGS,
SECTION_ID_STREAM_GROUP,
+SECTION_ID_STREAM_GROUP_COMPONENTS,
+SECTION_ID_STREAM_GROUP_COMPONENT,
+SECTION_ID_STREAM_GROUP_SUBCOMPONENTS,
+SECTION_ID_STREAM_GROUP_SUBCOMPONENT,
SECTION_ID_STREAM_GROUP_STREAMS,
SECTION_ID_STREAM_GROUP_STREAM,
SECTION_ID_STREAM_GROUP_DISPOSITION,
@@ -310,7 +315,11 @@ static struct section sections[] = {
[SECTION_ID_PROGRAMS] = { SECTION_ID_PROGRAMS,
"programs", SECTION_FLAG_IS_ARRAY, { SECTION_ID_PROGRAM, -1 } },
[SECTION_ID_STREAM_GROUP_STREAM_DISPOSITION] = {
SECTION_ID_STREAM_GROUP_STREAM_DISPOSITION, "disposition", 0, { -1 },
.unique_name = "stream_group_stream_disposition" },
[SECTION_ID_STREAM_GROUP_STREAM_TAGS] ={
SECTION_ID_STREAM_GROUP_STREAM_TAGS, "tags", SECTION_FLAG_HAS_VARIABLE_FIELDS,
{ -1 }, .element_name = "tag", .unique_name = "stream_group_stream_tags" },
-[SECTION_ID_STREAM_GROUP] ={ SECTION_ID_STREAM_GROUP,
"stream_group", SECTION_FLAG_HAS_TYPE, { SECTION_ID_STREAM_GROUP_TAGS,
SECTION_ID_STREAM_GROUP_DISPOSITION, SECTION_ID_STREAM_GROUP_STREAMS, -1 },
.get_type = get_stream_group_type },
+[SECTION_ID_STREAM_GROUP] ={ SECTION_ID_STREAM_GROUP,
"stream_group", 0, { SECTION_ID_STREAM_GROUP_TAGS,
SECTION_ID_STREAM_GROUP_DISPOSITION, SECTION_ID_STREAM_GROUP_COMPONENTS,
SECTION_ID_STREAM_GROUP_STREAMS, -1 } },
+[SECTION_ID_STREAM_GROUP_COMPONENTS] = {
SECTION_ID_STREAM_GROUP_COMPONENTS, "components", SECTION_FLAG_IS_ARRAY, {
SECTION_ID_STREAM_GROUP_COMPONENT, -1 }, .element_name = "component",
.unique_name = "stream_group_components" },
+[SECTION_ID_STREAM_GROUP_COMPONENT] = {
SECTION_ID_STREAM_GROUP_COMPONENT, "component",
SECTION_FLAG_HAS_VARIABLE_FIELDS|SECTION_FLAG_HAS_TYPE, {
SECTION_ID_STREAM_GROUP_SUBCOMPONENTS, -1 }, .unique_name =
"stream_group_component", .element_name = "component_entry", .get_type =
get_stream_group_type },
+[SECTION_ID_STREAM_GROUP_SUBCOMPONENTS] = {
SECTION_ID_STREAM_GROUP_SUBCOMPONENTS, "subcomponents", SECTION_FLAG_IS_ARRAY,
{ SECTION_ID_STREAM_GROUP_SUBCOMPONENT, -1 }, .element_name = "component" },
+[SECTION_ID_STREAM_GROUP_SUBCOMPONENT] = {
SECTION_ID_STREAM_GROUP_SUBCOMPONENT, "subcomponent",
SECTION_FLAG_HAS_VARIABLE_FIELDS|SECTION_FLAG_HAS_TYPE, { -1 }, .element_name =
"subcomponent_entry", .get_type = get_raw_string_type },
[SECTION_ID_STREAM_GROUP_STREAMS] ={
SECTION_ID_STREAM_GROUP_STREAMS, "streams", SECTION_FLAG_IS_ARRAY, {
SECTION_ID_STREAM_GROUP_STREAM, -1 }, .unique_name = "stream_group_streams" },
[SECTION_ID_STREAM_GROUP_STREAM] = {
SECTION_ID_STREAM_GROUP_STREAM, "stream", 0, {
SECTION_ID_STREAM_GROUP_STREAM_DISPOSITION,
SECTION_ID_STREAM_GROUP_STREAM_TAGS, -1 }, .unique_name = "stream_group_stream"
},
[SECTION_ID_STREAM_GROUP_DISPOSITION] ={
SECTION_ID_STREAM_GROUP_DISPOSITION, "disposition", 0, { -1 }, .unique_name =
"stream_group_disposition" },
@@ -3491,13 +3500,35 @@ static int show_programs(WriterContext *w, InputFile
*ifile)
return ret;
}
+static void print_tile_grid_params(WriterContext *w, const AVStreamGroup *stg,
+ const AVStreamGroupTileGrid *tile_grid)
+{
+
[FFmpeg-devel] [PATCH] avformat/mxfdec: signal channel layouts using the new channel layout api
Signed-off-by: Marton Balint
---
libavformat/mxfdec.c | 129 ++-
1 file changed, 53 insertions(+), 76 deletions(-)
diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c
index 289db9833c..e2f4a22983 100644
--- a/libavformat/mxfdec.c
+++ b/libavformat/mxfdec.c
@@ -188,8 +188,6 @@ typedef struct {
int body_sid;
MXFWrappingScheme wrapping;
int edit_units_per_packet; /* how many edit units to read at a time (PCM,
ClipWrapped) */
-int require_reordering;
-int channel_ordering[FF_SANE_NB_CHANNELS];
} MXFTrack;
typedef struct MXFDescriptor {
@@ -1652,48 +1650,48 @@ static const MXFCodecUL
mxf_data_essence_container_uls[] = {
typedef struct MXFChannelOrderingUL {
UID uid;
-uint64_t layout_mask;
+enum AVChannel channel;
enum AVAudioServiceType service_type;
} MXFChannelOrderingUL;
static const MXFChannelOrderingUL mxf_channel_ordering[] = {
-{ {
0x06,0x0e,0x2b,0x34,0x04,0x01,0x01,0x0d,0x03,0x02,0x01,0x01,0x00,0x00,0x00,0x00
}, AV_CH_FRONT_LEFT,AV_AUDIO_SERVICE_TYPE_MAIN }, // Left
-{ {
0x06,0x0e,0x2b,0x34,0x04,0x01,0x01,0x0d,0x03,0x02,0x01,0x02,0x00,0x00,0x00,0x00
}, AV_CH_FRONT_RIGHT, AV_AUDIO_SERVICE_TYPE_MAIN }, // Right
-{ {
0x06,0x0e,0x2b,0x34,0x04,0x01,0x01,0x0d,0x03,0x02,0x01,0x03,0x00,0x00,0x00,0x00
}, AV_CH_FRONT_CENTER, AV_AUDIO_SERVICE_TYPE_MAIN }, // Center
-{ {
0x06,0x0e,0x2b,0x34,0x04,0x01,0x01,0x0d,0x03,0x02,0x01,0x04,0x00,0x00,0x00,0x00
}, AV_CH_LOW_FREQUENCY, AV_AUDIO_SERVICE_TYPE_MAIN }, // Low Frequency
Effects
-{ {
0x06,0x0e,0x2b,0x34,0x04,0x01,0x01,0x0d,0x03,0x02,0x01,0x05,0x00,0x00,0x00,0x00
}, AV_CH_SIDE_LEFT, AV_AUDIO_SERVICE_TYPE_MAIN }, // Left Surround
-{ {
0x06,0x0e,0x2b,0x34,0x04,0x01,0x01,0x0d,0x03,0x02,0x01,0x06,0x00,0x00,0x00,0x00
}, AV_CH_SIDE_RIGHT,AV_AUDIO_SERVICE_TYPE_MAIN }, // Right Surround
-{ {
0x06,0x0e,0x2b,0x34,0x04,0x01,0x01,0x0d,0x03,0x02,0x01,0x07,0x00,0x00,0x00,0x00
}, AV_CH_SIDE_LEFT, AV_AUDIO_SERVICE_TYPE_MAIN }, // Left Side
Surround
-{ {
0x06,0x0e,0x2b,0x34,0x04,0x01,0x01,0x0d,0x03,0x02,0x01,0x08,0x00,0x00,0x00,0x00
}, AV_CH_SIDE_RIGHT,AV_AUDIO_SERVICE_TYPE_MAIN }, // Right Side
Surround
-{ {
0x06,0x0e,0x2b,0x34,0x04,0x01,0x01,0x0d,0x03,0x02,0x01,0x09,0x00,0x00,0x00,0x00
}, AV_CH_BACK_LEFT, AV_AUDIO_SERVICE_TYPE_MAIN }, // Left Rear
Surround
-{ {
0x06,0x0e,0x2b,0x34,0x04,0x01,0x01,0x0d,0x03,0x02,0x01,0x0a,0x00,0x00,0x00,0x00
}, AV_CH_BACK_RIGHT,AV_AUDIO_SERVICE_TYPE_MAIN }, // Right Rear
Surround
-{ {
0x06,0x0e,0x2b,0x34,0x04,0x01,0x01,0x0d,0x03,0x02,0x01,0x0b,0x00,0x00,0x00,0x00
}, AV_CH_FRONT_LEFT_OF_CENTER, AV_AUDIO_SERVICE_TYPE_MAIN }, // Left Center
-{ {
0x06,0x0e,0x2b,0x34,0x04,0x01,0x01,0x0d,0x03,0x02,0x01,0x0c,0x00,0x00,0x00,0x00
}, AV_CH_FRONT_RIGHT_OF_CENTER, AV_AUDIO_SERVICE_TYPE_MAIN }, // Right Center
-{ {
0x06,0x0e,0x2b,0x34,0x04,0x01,0x01,0x0d,0x03,0x02,0x01,0x0d,0x00,0x00,0x00,0x00
}, AV_CH_BACK_CENTER, AV_AUDIO_SERVICE_TYPE_MAIN }, // Center Surround
-{ {
0x06,0x0e,0x2b,0x34,0x04,0x01,0x01,0x0d,0x03,0x02,0x01,0x0e,0x00,0x00,0x00,0x00
}, AV_CH_FRONT_CENTER, AV_AUDIO_SERVICE_TYPE_VISUALLY_IMPAIRED }, //
Hearing impaired audio channel
-{ {
0x06,0x0e,0x2b,0x34,0x04,0x01,0x01,0x0d,0x03,0x02,0x01,0x0f,0x00,0x00,0x00,0x00
}, AV_CH_FRONT_CENTER, AV_AUDIO_SERVICE_TYPE_HEARING_IMPAIRED }, //
Visually impaired narrative audio channel
-{ {
0x06,0x0e,0x2b,0x34,0x04,0x01,0x01,0x0d,0x03,0x02,0x01,0x20,0x03,0x00,0x00,0x00
}, AV_CH_STEREO_LEFT, AV_AUDIO_SERVICE_TYPE_MAIN }, // Left Total
-{ {
0x06,0x0e,0x2b,0x34,0x04,0x01,0x01,0x0d,0x03,0x02,0x01,0x20,0x04,0x00,0x00,0x00
}, AV_CH_STEREO_RIGHT, AV_AUDIO_SERVICE_TYPE_MAIN }, // Right Total
-{ {
0x06,0x0e,0x2b,0x34,0x04,0x01,0x01,0x0d,0x03,0x02,0x01,0x30,0x01,0x01,0x00,0x00
}, AV_CH_TOP_FRONT_LEFT,AV_AUDIO_SERVICE_TYPE_MAIN }, // Left Height
-{ {
0x06,0x0e,0x2b,0x34,0x04,0x01,0x01,0x0d,0x03,0x02,0x01,0x30,0x01,0x02,0x00,0x00
}, AV_CH_TOP_FRONT_RIGHT, AV_AUDIO_SERVICE_TYPE_MAIN }, // Right Height
-{ {
0x06,0x0e,0x2b,0x34,0x04,0x01,0x01,0x0d,0x03,0x02,0x01,0x30,0x01,0x03,0x00,0x00
}, AV_CH_TOP_FRONT_CENTER, AV_AUDIO_SERVICE_TYPE_MAIN }, // Center Height
-{ {
0x06,0x0e,0x2b,0x34,0x04,0x01,0x01,0x0d,0x03,0x02,0x01,0x30,0x01,0x04,0x00,0x00
}, AV_CH_TOP_SIDE_LEFT, AV_AUDIO_SERVICE_TYPE_MAIN }, // Left Surround
Height
-{ {
0x06,0x0e,0x2b,0x34,0x04,0x01,0x01,0x0d,0x03,0x02,0x01,0x30,0x01,0x05,0x00,0x00
}, AV_CH_TOP_SIDE_RIGHT,AV_AUDIO_SERVICE_TYPE_MAIN }, // Right Surround
Height
-{ {
0x06,0x0e,0x2b,0x34,0x04,0x01,0x01,0x0d,0x03,0x02,0x01,0x30,0x01,0x06,0x00,0x00
}, AV_CH_TOP_SIDE_LEFT, AV_AUDIO_SERVICE_TYPE_MAIN }, // Left Side
Surround Height
-{ {
Re: [FFmpeg-devel] [PATCH 2/3] lavc: replace ff_thread_get_buffer() with ff_get_buffer()
On Fri, Mar 8, 2024 at 6:01 PM Kieran Kunhya wrote: > On Fri, 8 Mar 2024 at 16:50, Nicolas George wrote: > > > Kieran Kunhya (12024-03-08): > > > New contributors are not interested in your biased history lessons. > They > > > want to write code and have a modern, well run project, not a > > dysfunctional > > > mess. > > > > And we go back to the core question: does the strength of this project > > come from paid-for contributors maintaining each small parts of the > > project, or does it come from hackers who play with many parts of the > > code and have original ideas to try? > > > > I think the answer is obvious. > > > > Unfortunately, the first category is the majority in number. Which is > > why we should go back on democracy, it was a trap, and re-instate a > > project leader from the second category. Or just consider that the > > ousting of the leader was unlawful. > > > > The world moved on. Open Source projects which are anarchy are few and far > between (basically us). New contributors prefer stability over chaos. > What's worrisome is that old contributors who don't agree with the status quo are free to fork the project and create their own utopia, I don't understand how being in an abusive relationship with this project is any beneficial to OP or the project itself. -- Vittorio ___ 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".
Re: [FFmpeg-devel] [PATCH 2/3] lavc: replace ff_thread_get_buffer() with ff_get_buffer()
On Fri, 8 Mar 2024 at 16:50, Nicolas George wrote: > Kieran Kunhya (12024-03-08): > > New contributors are not interested in your biased history lessons. They > > want to write code and have a modern, well run project, not a > dysfunctional > > mess. > > And we go back to the core question: does the strength of this project > come from paid-for contributors maintaining each small parts of the > project, or does it come from hackers who play with many parts of the > code and have original ideas to try? > > I think the answer is obvious. > > Unfortunately, the first category is the majority in number. Which is > why we should go back on democracy, it was a trap, and re-instate a > project leader from the second category. Or just consider that the > ousting of the leader was unlawful. > The world moved on. Open Source projects which are anarchy are few and far between (basically us). New contributors prefer stability over chaos. Kieran ___ 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".
Re: [FFmpeg-devel] [PATCH 2/3] lavc: replace ff_thread_get_buffer() with ff_get_buffer()
Kieran Kunhya (12024-03-08): > New contributors are not interested in your biased history lessons. They > want to write code and have a modern, well run project, not a dysfunctional > mess. And we go back to the core question: does the strength of this project come from paid-for contributors maintaining each small parts of the project, or does it come from hackers who play with many parts of the code and have original ideas to try? I think the answer is obvious. Unfortunately, the first category is the majority in number. Which is why we should go back on democracy, it was a trap, and re-instate a project leader from the second category. Or just consider that the ousting of the leader was unlawful. -- Nicolas George ___ 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".
Re: [FFmpeg-devel] [PATCH 2/3] lavc: replace ff_thread_get_buffer() with ff_get_buffer()
On Fri, 8 Mar 2024 at 16:41, Nicolas George wrote: > Kieran Kunhya (12024-03-08): > > Several recent contributors were in nappies during that piece of ancient > > history. Do you really need to bring it up incessantly and use it as your > > prism on every issue you disagree with? > > Yes, it is necessary, because the same thing is happening again. “Those > who cannot learn from history are doomed to repeat it.” New contributors > who are not familiar with these events need to ear of them all the more > New contributors are not interested in your biased history lessons. They want to write code and have a modern, well run project, not a dysfunctional mess. Kieran ___ 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".
Re: [FFmpeg-devel] [PATCH 2/3] lavc: replace ff_thread_get_buffer() with ff_get_buffer()
Kieran Kunhya (12024-03-08): > Several recent contributors were in nappies during that piece of ancient > history. Do you really need to bring it up incessantly and use it as your > prism on every issue you disagree with? Yes, it is necessary, because the same thing is happening again. “Those who cannot learn from history are doomed to repeat it.” New contributors who are not familiar with these events need to ear of them all the more. -- Nicolas George ___ 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".
Re: [FFmpeg-devel] [PATCH 2/3] lavc: replace ff_thread_get_buffer() with ff_get_buffer()
Ronald S. Bultje (12024-03-08): > I hope you realize that is what reconciliation looks like. No, it is not. It is what a takeover disguised as reconciliation looks like. -- Nicolas George ___ 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".
Re: [FFmpeg-devel] [PATCH 2/3] lavc: replace ff_thread_get_buffer() with ff_get_buffer()
Hi Nicolas, On Fri, Mar 8, 2024 at 10:46 AM Nicolas George wrote: > [..] you can see they have in the recent years gained a > lot of influence in FFmpeg [..] > I hope you realize that is what reconciliation looks like. In other words: this was always the goal - from both "sides". You seem to be the only one disagreeing with this goal. Everyone else seems to like having experts from both "sides" work together with - not against - each other. Or in plainer terms: you're gonna have to get used to this new normal. This is it. Welcome to the new & better FFmpeg. I genuinely hope you like it. Ronald ___ 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".
Re: [FFmpeg-devel] [PATCH 2/3] lavc: replace ff_thread_get_buffer() with ff_get_buffer()
On Fri, 8 Mar 2024 at 15:46, Nicolas George wrote: > Sean McGovern (12024-03-08): > > It is really mean-spirited to make such comments about a project that is > no > > longer in operation. Can't we look forward instead of behind us? > > The project libav might be dead, but the people who made it are not, not > even retired, just look who signed its manifest. > > Quite the opposite, you can see they have in the recent years gained a > lot of influence in FFmpeg, and are now in the process of having FFmpeg > apply the same kind of rules and procedure and evolution ad libav. Which > is not a good idea considering the killed libav with these rules and > procedures and evolution. > Several recent contributors were in nappies during that piece of ancient history. Do you really need to bring it up incessantly and use it as your prism on every issue you disagree with? Kieran ___ 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".
Re: [FFmpeg-devel] [PATCH] avfilter/fifo: Remove (a)fifo filters
Muhammad Faiz: > On Fri, Mar 8, 2024 at 5:40 PM Andreas Rheinhardt < > andreas.rheinha...@outlook.com> wrote: > >> Muhammad Faiz: >>> On Tue, Feb 6, 2024 at 3:58 PM Andreas Rheinhardt < >>> andreas.rheinha...@outlook.com> wrote: >>> Andreas Rheinhardt: > Obsolete since 4ca1fb9d2a91757c8c4c34dd456abf340e3f765f. > > Signed-off-by: Andreas Rheinhardt > --- > doc/filters.texi | 9 --- > libavfilter/Makefile | 1 - > libavfilter/allfilters.c | 2 - > libavfilter/fifo.c | 165 --- > 4 files changed, 177 deletions(-) > delete mode 100644 libavfilter/fifo.c > Will apply in a few days unless there are objections. - Andreas >>> This breaks backward compatibility. >>> >>> Please revert. >>> >>> Thank's. >> >> What breaks that can't simply be fixed by removing the (a)fifo filter >> from the filterchain? >> >> - Andreas >> >> > I use afifo to optimize memory usage. > And backward incompatible change should only be allowed with deprecation > periods and major version bump. > Deprecation periods etc. are only common for API breaks; we do not guarantee that any particular filter etc. stays available and therefore occasionally remove them without deprecation. Examples of this are the removal of libopenjpeg in 60ccb3fe787, the removal of libwavpackenc in 45070eec4c or the removal of the XvMC hardware acceleration in be95df12bb06 (the last commit was accompanied by cefa595361db9 and b648ece34b6f which deprecated the parts of XvMC that were part of the public API and therefore subject to the API stability contract). - Andreas ___ 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".
Re: [FFmpeg-devel] [PATCH 2/3] lavc: replace ff_thread_get_buffer() with ff_get_buffer()
Sean McGovern (12024-03-08): > It is really mean-spirited to make such comments about a project that is no > longer in operation. Can't we look forward instead of behind us? The project libav might be dead, but the people who made it are not, not even retired, just look who signed its manifest. Quite the opposite, you can see they have in the recent years gained a lot of influence in FFmpeg, and are now in the process of having FFmpeg apply the same kind of rules and procedure and evolution ad libav. Which is not a good idea considering the killed libav with these rules and procedures and evolution. -- Nicolas George ___ 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".
Re: [FFmpeg-devel] [PATCH 2/3] lavc: replace ff_thread_get_buffer() with ff_get_buffer()
On Fri, Mar 8, 2024, 10:37 Vittorio Giovara wrote: > On Fri, Mar 8, 2024 at 4:34 PM Sean McGovern wrote: > > > On Fri, Mar 8, 2024, 10:31 Paul B Mahol wrote: > > > > > On Fri, Mar 8, 2024 at 4:21 PM Vittorio Giovara < > > > vittorio.giov...@gmail.com> > > > wrote: > > > > > > > On Fri, Mar 8, 2024 at 4:10 PM Sean McGovern > > wrote: > > > > > > > > > On Fri, Mar 8, 2024, 08:20 Nicolas George wrote: > > > > > > > > > > > Andreas Rheinhardt (12024-03-08): > > > > > > > What maintenance cost and complexity are you referring to? I > > > checked > > > > > and > > > > > > > could not find a single commit where one had to fix an > > > > ff_get_buffer() > > > > > > > to ff_thread_get_buffer() because it has been forgotten when > the > > > > > decoder > > > > > > > has been declared to support frame threading. > > > > > > > > > > > > Welcome to the new FFmpeg, where absolute consistency, i.e. > > catering > > > > for > > > > > > hypothetical mediocre contributors, is more important than easy > > > > > > optimizations and new approaches. > > > > > > > > > > > > And if you do not like it, “shut up, I'm on the TC and I won't > > > recuse”. > > > > > > > > > > > > And if you do not like that, “shut up, I'm on the CC too”. > > > > > > > > > > > > Regards, > > > > > > > > > > > > -- > > > > > > Nicolas George > > > > > > ___ > > > > > > 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". > > > > > > > > > > > > > > > > Everybody can we *please* keep the responses civil/professional on > > the > > > > ML. > > > > > > > > > > > > > I'd just be happy with "on-topic" but it seems like people with > agendas > > > > like to project on unrelated threads. > > > > > > > > > > LibAV actions speak more than words once again. > > > > > > > > > > -- > > > > Vittorio > > > > ___ > > > > 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". > > > > > > > ___ > > > 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". > > > > > > > It is really mean-spirited to make such comments about a project that is > no > > longer in operation. Can't we look forward instead of behind us? > > > > Could you guys look forward in a separate thread? > -- > Vittorio > ___ > 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". > I see what you did there (ref: $subj)! :) -- Sean McGovern ___ 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".
Re: [FFmpeg-devel] FFmpeg 7.0 blocking issues
On Fri, 8 Mar 2024 at 15:04, Frank Plowman wrote: > On 08/03/2024 14:04, James Almer wrote: > > On 3/8/2024 11:02 AM, Kieran Kunhya wrote: > >> On Fri, 8 Mar 2024 at 14:00, James Almer wrote: > >> > >>> On 3/3/2024 4:35 AM, Jean-Baptiste Kempf wrote: > > n Sat, 2 Mar 2024, at 23:55, Michael Niedermayer wrote: > > On Tue, Jan 23, 2024 at 08:22:41PM +0100, Michael Niedermayer wrote: > >> Hi all > >> > >> As it was a little difficult for me to not loose track of what is > >> blocking a release. I suggest that for all release blocking issues > >> open a ticket and set Blocking to 7.0 > >> that way this: > >> https://trac.ffmpeg.org/query?blocking=~7.0 > >> > >> or for the ones not closed: > >> > >>> > https://trac.ffmpeg.org/query?status=new=open=reopened=~7.0 > >> > >> will list all blocking issues > >> > >> Ive added one, for testing that, i intend to add more if i see > >>> something > >> > >> What is blocking? (IMHO) > >> * regressions (unless its non possible to fix before release) > >> * crashes > >> * security issues > >> * data loss > >> * privacy issues > >> * anything the commuity agrees should be in the release > > > > We still have 3 blocking issues on trac > > > > do people want me to wait or ignore them and branch ? > > I think you can branch soon. > However, those 3 bugs are quite important, tbh. > >>> > >>> The bump and the AVOption changes were already applied, so IMO we can > >>> branch. > >>> The two remaining issues should not be blocking as they can be > >>> backported to 7.0 in a point release. > >>> > >> > >> VVC experimental flag is blocking. > >> > >> Kieran > > > > Is there a patch for that? > > There is this: > https://ffmpeg.org//pipermail/ffmpeg-devel/2024-February/321060.html > (missing from patchwork for some reason), but it looks like it causes > FATE to fail as is. > Yes it does not update FATE to account for experimental. Kieran ___ 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".
Re: [FFmpeg-devel] [PATCH 2/3] lavc: replace ff_thread_get_buffer() with ff_get_buffer()
On Fri, Mar 8, 2024 at 4:34 PM Sean McGovern wrote: > On Fri, Mar 8, 2024, 10:31 Paul B Mahol wrote: > > > On Fri, Mar 8, 2024 at 4:21 PM Vittorio Giovara < > > vittorio.giov...@gmail.com> > > wrote: > > > > > On Fri, Mar 8, 2024 at 4:10 PM Sean McGovern > wrote: > > > > > > > On Fri, Mar 8, 2024, 08:20 Nicolas George wrote: > > > > > > > > > Andreas Rheinhardt (12024-03-08): > > > > > > What maintenance cost and complexity are you referring to? I > > checked > > > > and > > > > > > could not find a single commit where one had to fix an > > > ff_get_buffer() > > > > > > to ff_thread_get_buffer() because it has been forgotten when the > > > > decoder > > > > > > has been declared to support frame threading. > > > > > > > > > > Welcome to the new FFmpeg, where absolute consistency, i.e. > catering > > > for > > > > > hypothetical mediocre contributors, is more important than easy > > > > > optimizations and new approaches. > > > > > > > > > > And if you do not like it, “shut up, I'm on the TC and I won't > > recuse”. > > > > > > > > > > And if you do not like that, “shut up, I'm on the CC too”. > > > > > > > > > > Regards, > > > > > > > > > > -- > > > > > Nicolas George > > > > > ___ > > > > > 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". > > > > > > > > > > > > > Everybody can we *please* keep the responses civil/professional on > the > > > ML. > > > > > > > > > > I'd just be happy with "on-topic" but it seems like people with agendas > > > like to project on unrelated threads. > > > > > > > LibAV actions speak more than words once again. > > > > > > > -- > > > Vittorio > > > ___ > > > 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". > > > > > ___ > > 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". > > > > It is really mean-spirited to make such comments about a project that is no > longer in operation. Can't we look forward instead of behind us? > Could you guys look forward in a separate thread? -- Vittorio ___ 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".
Re: [FFmpeg-devel] [PATCH 2/3] lavc: replace ff_thread_get_buffer() with ff_get_buffer()
On Fri, Mar 8, 2024, 10:31 Paul B Mahol wrote: > On Fri, Mar 8, 2024 at 4:21 PM Vittorio Giovara < > vittorio.giov...@gmail.com> > wrote: > > > On Fri, Mar 8, 2024 at 4:10 PM Sean McGovern wrote: > > > > > On Fri, Mar 8, 2024, 08:20 Nicolas George wrote: > > > > > > > Andreas Rheinhardt (12024-03-08): > > > > > What maintenance cost and complexity are you referring to? I > checked > > > and > > > > > could not find a single commit where one had to fix an > > ff_get_buffer() > > > > > to ff_thread_get_buffer() because it has been forgotten when the > > > decoder > > > > > has been declared to support frame threading. > > > > > > > > Welcome to the new FFmpeg, where absolute consistency, i.e. catering > > for > > > > hypothetical mediocre contributors, is more important than easy > > > > optimizations and new approaches. > > > > > > > > And if you do not like it, “shut up, I'm on the TC and I won't > recuse”. > > > > > > > > And if you do not like that, “shut up, I'm on the CC too”. > > > > > > > > Regards, > > > > > > > > -- > > > > Nicolas George > > > > ___ > > > > 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". > > > > > > > > > > Everybody can we *please* keep the responses civil/professional on the > > ML. > > > > > > > I'd just be happy with "on-topic" but it seems like people with agendas > > like to project on unrelated threads. > > > > LibAV actions speak more than words once again. > > > > -- > > Vittorio > > ___ > > 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". > > > ___ > 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". > It is really mean-spirited to make such comments about a project that is no longer in operation. Can't we look forward instead of behind us? -- Sean McGovern ___ 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".
Re: [FFmpeg-devel] [PATCH 2/3] lavc: replace ff_thread_get_buffer() with ff_get_buffer()
On Fri, Mar 8, 2024 at 4:21 PM Vittorio Giovara wrote: > On Fri, Mar 8, 2024 at 4:10 PM Sean McGovern wrote: > > > On Fri, Mar 8, 2024, 08:20 Nicolas George wrote: > > > > > Andreas Rheinhardt (12024-03-08): > > > > What maintenance cost and complexity are you referring to? I checked > > and > > > > could not find a single commit where one had to fix an > ff_get_buffer() > > > > to ff_thread_get_buffer() because it has been forgotten when the > > decoder > > > > has been declared to support frame threading. > > > > > > Welcome to the new FFmpeg, where absolute consistency, i.e. catering > for > > > hypothetical mediocre contributors, is more important than easy > > > optimizations and new approaches. > > > > > > And if you do not like it, “shut up, I'm on the TC and I won't recuse”. > > > > > > And if you do not like that, “shut up, I'm on the CC too”. > > > > > > Regards, > > > > > > -- > > > Nicolas George > > > ___ > > > 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". > > > > > > > Everybody can we *please* keep the responses civil/professional on the > ML. > > > > I'd just be happy with "on-topic" but it seems like people with agendas > like to project on unrelated threads. > LibAV actions speak more than words once again. > -- > Vittorio > ___ > 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". > ___ 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".
Re: [FFmpeg-devel] [PATCH] avfilter/fifo: Remove (a)fifo filters
On Fri, Mar 8, 2024 at 4:18 PM Muhammad Faiz wrote: > On Fri, Mar 8, 2024 at 5:40 PM Andreas Rheinhardt < > andreas.rheinha...@outlook.com> wrote: > > > Muhammad Faiz: > > > On Tue, Feb 6, 2024 at 3:58 PM Andreas Rheinhardt < > > > andreas.rheinha...@outlook.com> wrote: > > > > > >> Andreas Rheinhardt: > > >>> Obsolete since 4ca1fb9d2a91757c8c4c34dd456abf340e3f765f. > > >>> > > >>> Signed-off-by: Andreas Rheinhardt > > >>> --- > > >>> doc/filters.texi | 9 --- > > >>> libavfilter/Makefile | 1 - > > >>> libavfilter/allfilters.c | 2 - > > >>> libavfilter/fifo.c | 165 > --- > > >>> 4 files changed, 177 deletions(-) > > >>> delete mode 100644 libavfilter/fifo.c > > >>> > > >> > > >> Will apply in a few days unless there are objections. > > >> > > >> - Andreas > > >> > > >> > > > This breaks backward compatibility. > > > > > > Please revert. > > > > > > Thank's. > > > > What breaks that can't simply be fixed by removing the (a)fifo filter > > from the filterchain? > > > > - Andreas > > > > > I use afifo to optimize memory usage. > That statement sync with reality is questionable, fifo filters were mainly used before .activate was added, for cases filters used >1 inputs. Now they should be irrelevant, unless there are bugs in code than this filters just hide more bugs. > And backward incompatible change should only be allowed with deprecation > periods and major version bump. > > Thank's > ___ > 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". > ___ 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".
Re: [FFmpeg-devel] [PATCH 2/3] lavc: replace ff_thread_get_buffer() with ff_get_buffer()
On Fri, Mar 8, 2024, 10:19 Nicolas George wrote: > Sean McGovern (12024-03-08): > > Everybody can we *please* keep the responses civil/professional on the > ML. > > Civil, certainly, provided others are civil to me. > > Professional, not a chance. This is Libre Software, not a job. > > -- > Nicolas George > ___ > 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". > OK, sorry that was probably overstep, I agree and retract "professional" from that statement. -- Sean McGovern ___ 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".
Re: [FFmpeg-devel] [PATCH 2/3] lavc: replace ff_thread_get_buffer() with ff_get_buffer()
On Fri, Mar 8, 2024 at 4:10 PM Sean McGovern wrote: > On Fri, Mar 8, 2024, 08:20 Nicolas George wrote: > > > Andreas Rheinhardt (12024-03-08): > > > What maintenance cost and complexity are you referring to? I checked > and > > > could not find a single commit where one had to fix an ff_get_buffer() > > > to ff_thread_get_buffer() because it has been forgotten when the > decoder > > > has been declared to support frame threading. > > > > Welcome to the new FFmpeg, where absolute consistency, i.e. catering for > > hypothetical mediocre contributors, is more important than easy > > optimizations and new approaches. > > > > And if you do not like it, “shut up, I'm on the TC and I won't recuse”. > > > > And if you do not like that, “shut up, I'm on the CC too”. > > > > Regards, > > > > -- > > Nicolas George > > ___ > > 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". > > > > Everybody can we *please* keep the responses civil/professional on the ML. > I'd just be happy with "on-topic" but it seems like people with agendas like to project on unrelated threads. -- Vittorio ___ 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".
Re: [FFmpeg-devel] [PATCH 2/3] lavc: replace ff_thread_get_buffer() with ff_get_buffer()
Sean McGovern (12024-03-08): > Everybody can we *please* keep the responses civil/professional on the ML. Civil, certainly, provided others are civil to me. Professional, not a chance. This is Libre Software, not a job. -- Nicolas George ___ 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".
Re: [FFmpeg-devel] [PATCH] avfilter/fifo: Remove (a)fifo filters
On Fri, Mar 8, 2024 at 5:40 PM Andreas Rheinhardt < andreas.rheinha...@outlook.com> wrote: > Muhammad Faiz: > > On Tue, Feb 6, 2024 at 3:58 PM Andreas Rheinhardt < > > andreas.rheinha...@outlook.com> wrote: > > > >> Andreas Rheinhardt: > >>> Obsolete since 4ca1fb9d2a91757c8c4c34dd456abf340e3f765f. > >>> > >>> Signed-off-by: Andreas Rheinhardt > >>> --- > >>> doc/filters.texi | 9 --- > >>> libavfilter/Makefile | 1 - > >>> libavfilter/allfilters.c | 2 - > >>> libavfilter/fifo.c | 165 --- > >>> 4 files changed, 177 deletions(-) > >>> delete mode 100644 libavfilter/fifo.c > >>> > >> > >> Will apply in a few days unless there are objections. > >> > >> - Andreas > >> > >> > > This breaks backward compatibility. > > > > Please revert. > > > > Thank's. > > What breaks that can't simply be fixed by removing the (a)fifo filter > from the filterchain? > > - Andreas > > I use afifo to optimize memory usage. And backward incompatible change should only be allowed with deprecation periods and major version bump. Thank's ___ 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".
[FFmpeg-devel] Did FATE have an unhappy accident?
It's been unreachable since yesterday. -- Sean McGovern ___ 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".
Re: [FFmpeg-devel] [PATCH] fate: fix sub2video_{basic, time_limited} on big-endian targets
On Wed, Mar 6, 2024, 18:48 Sean McGovern wrote: > The reference file uses BGRA pixel format, so request it here. > --- > tests/fate/ffmpeg.mak | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/tests/fate/ffmpeg.mak b/tests/fate/ffmpeg.mak > index 669c878c7f..77e93693b9 100644 > --- a/tests/fate/ffmpeg.mak > +++ b/tests/fate/ffmpeg.mak > @@ -62,6 +62,7 @@ fate-sub2video: CMD = framecrc -auto_conversion_filters \ > FATE_SAMPLES_FFMPEG-$(call FRAMECRC, VOBSUB, DVDSUB, SCALE_FILTER) += > fate-sub2video_basic > fate-sub2video_basic: CMD = framecrc -auto_conversion_filters \ >-i $(TARGET_SAMPLES)/sub/vobsub.idx \ > + -pix_fmt bgra \ >-fps_mode passthrough -copyts \ >-filter_complex "sws_flags=+accurate_rnd+bitexact\;[0:s:0]scale" \ >-c:v rawvideo -threads 1 > @@ -71,6 +72,7 @@ fate-sub2video_basic: CMD = framecrc > -auto_conversion_filters \ > FATE_SAMPLES_FFMPEG-$(call FRAMECRC, SUP, PGSSUB, SCALE_FILTER > RAWVIDEO_ENCODER) += fate-sub2video_time_limited > fate-sub2video_time_limited: CMD = framecrc -auto_conversion_filters \ >-i $(TARGET_SAMPLES)/sub/pgs_sub.sup \ > + -pix_fmt bgra \ >-fps_mode passthrough -copyts \ >-t 15 \ >-filter_complex "sws_flags=+accurate_rnd+bitexact\;[0:s:0]scale" \ > -- > 2.39.2 > Ping review, if someone has some cycle. -- Sean McGovern ___ 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".
Re: [FFmpeg-devel] [PATCH 2/3] lavc: replace ff_thread_get_buffer() with ff_get_buffer()
On Fri, Mar 8, 2024, 08:20 Nicolas George wrote: > Andreas Rheinhardt (12024-03-08): > > What maintenance cost and complexity are you referring to? I checked and > > could not find a single commit where one had to fix an ff_get_buffer() > > to ff_thread_get_buffer() because it has been forgotten when the decoder > > has been declared to support frame threading. > > Welcome to the new FFmpeg, where absolute consistency, i.e. catering for > hypothetical mediocre contributors, is more important than easy > optimizations and new approaches. > > And if you do not like it, “shut up, I'm on the TC and I won't recuse”. > > And if you do not like that, “shut up, I'm on the CC too”. > > Regards, > > -- > Nicolas George > ___ > 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". > Everybody can we *please* keep the responses civil/professional on the ML. -- Sean McGovern ___ 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".
Re: [FFmpeg-devel] FFmpeg 7.0 blocking issues
On 08/03/2024 14:04, James Almer wrote: > On 3/8/2024 11:02 AM, Kieran Kunhya wrote: >> On Fri, 8 Mar 2024 at 14:00, James Almer wrote: >> >>> On 3/3/2024 4:35 AM, Jean-Baptiste Kempf wrote: n Sat, 2 Mar 2024, at 23:55, Michael Niedermayer wrote: > On Tue, Jan 23, 2024 at 08:22:41PM +0100, Michael Niedermayer wrote: >> Hi all >> >> As it was a little difficult for me to not loose track of what is >> blocking a release. I suggest that for all release blocking issues >> open a ticket and set Blocking to 7.0 >> that way this: >> https://trac.ffmpeg.org/query?blocking=~7.0 >> >> or for the ones not closed: >> >>> https://trac.ffmpeg.org/query?status=new=open=reopened=~7.0 >> >> will list all blocking issues >> >> Ive added one, for testing that, i intend to add more if i see >>> something >> >> What is blocking? (IMHO) >> * regressions (unless its non possible to fix before release) >> * crashes >> * security issues >> * data loss >> * privacy issues >> * anything the commuity agrees should be in the release > > We still have 3 blocking issues on trac > > do people want me to wait or ignore them and branch ? I think you can branch soon. However, those 3 bugs are quite important, tbh. >>> >>> The bump and the AVOption changes were already applied, so IMO we can >>> branch. >>> The two remaining issues should not be blocking as they can be >>> backported to 7.0 in a point release. >>> >> >> VVC experimental flag is blocking. >> >> Kieran > > Is there a patch for that? There is this: https://ffmpeg.org//pipermail/ffmpeg-devel/2024-February/321060.html (missing from patchwork for some reason), but it looks like it causes FATE to fail as is. ___ 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".
Re: [FFmpeg-devel] [PATCH 2/3] lavc: replace ff_thread_get_buffer() with ff_get_buffer()
On Fri, Mar 8, 2024 at 12:18 PM Andreas Rheinhardt < andreas.rheinha...@outlook.com> wrote: > >> > >> -1: This adds avoidable runtime checks. > > > > What checks and why is that a problem? > > > It adds a runtime check to every call to ff_get_buffer() by every > decoder not supporting frame-threading (by checking whether > frame-threading is currently in use). > >>> > >>> I cannot imagine any situation where it could have a measurable impact. > >>> > >> > >> And? It is avoidable, therefore it should be avoided. > > > > Why should it be avoided when it can never have any measurable impact? > > > > The maintenance cost of a more complex API is higher than the > > infinitesimal cost of this check. > > > > What maintenance cost and complexity are you referring to? I checked and > could not find a single commit where one had to fix an ff_get_buffer() > to ff_thread_get_buffer() because it has been forgotten when the decoder > has been declared to support frame threading. > I'd wager documentation and developer complexity costs, usually a simpler API is a nice thing to have. Especially in this case, if the runtime check is minimal it doesn't make sense to keep two different APIs that do the same thing. -- Vittorio ___ 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".
Re: [FFmpeg-devel] FFmpeg 7.0 blocking issues
On 3/8/2024 11:02 AM, Kieran Kunhya wrote: On Fri, 8 Mar 2024 at 14:00, James Almer wrote: On 3/3/2024 4:35 AM, Jean-Baptiste Kempf wrote: n Sat, 2 Mar 2024, at 23:55, Michael Niedermayer wrote: On Tue, Jan 23, 2024 at 08:22:41PM +0100, Michael Niedermayer wrote: Hi all As it was a little difficult for me to not loose track of what is blocking a release. I suggest that for all release blocking issues open a ticket and set Blocking to 7.0 that way this: https://trac.ffmpeg.org/query?blocking=~7.0 or for the ones not closed: https://trac.ffmpeg.org/query?status=new=open=reopened=~7.0 will list all blocking issues Ive added one, for testing that, i intend to add more if i see something What is blocking? (IMHO) * regressions (unless its non possible to fix before release) * crashes * security issues * data loss * privacy issues * anything the commuity agrees should be in the release We still have 3 blocking issues on trac do people want me to wait or ignore them and branch ? I think you can branch soon. However, those 3 bugs are quite important, tbh. The bump and the AVOption changes were already applied, so IMO we can branch. The two remaining issues should not be blocking as they can be backported to 7.0 in a point release. VVC experimental flag is blocking. Kieran Is there a patch for that? ___ 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".
Re: [FFmpeg-devel] FFmpeg 7.0 blocking issues
On Fri, 8 Mar 2024 at 14:00, James Almer wrote: > On 3/3/2024 4:35 AM, Jean-Baptiste Kempf wrote: > > > > n Sat, 2 Mar 2024, at 23:55, Michael Niedermayer wrote: > >> On Tue, Jan 23, 2024 at 08:22:41PM +0100, Michael Niedermayer wrote: > >>> Hi all > >>> > >>> As it was a little difficult for me to not loose track of what is > >>> blocking a release. I suggest that for all release blocking issues > >>> open a ticket and set Blocking to 7.0 > >>> that way this: > >>> https://trac.ffmpeg.org/query?blocking=~7.0 > >>> > >>> or for the ones not closed: > >>> > https://trac.ffmpeg.org/query?status=new=open=reopened=~7.0 > >>> > >>> will list all blocking issues > >>> > >>> Ive added one, for testing that, i intend to add more if i see > something > >>> > >>> What is blocking? (IMHO) > >>> * regressions (unless its non possible to fix before release) > >>> * crashes > >>> * security issues > >>> * data loss > >>> * privacy issues > >>> * anything the commuity agrees should be in the release > >> > >> We still have 3 blocking issues on trac > >> > >> do people want me to wait or ignore them and branch ? > > > > I think you can branch soon. > > However, those 3 bugs are quite important, tbh. > > The bump and the AVOption changes were already applied, so IMO we can > branch. > The two remaining issues should not be blocking as they can be > backported to 7.0 in a point release. > VVC experimental flag is blocking. Kieran ___ 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".
Re: [FFmpeg-devel] FFmpeg 7.0 blocking issues
On 3/3/2024 4:35 AM, Jean-Baptiste Kempf wrote: n Sat, 2 Mar 2024, at 23:55, Michael Niedermayer wrote: On Tue, Jan 23, 2024 at 08:22:41PM +0100, Michael Niedermayer wrote: Hi all As it was a little difficult for me to not loose track of what is blocking a release. I suggest that for all release blocking issues open a ticket and set Blocking to 7.0 that way this: https://trac.ffmpeg.org/query?blocking=~7.0 or for the ones not closed: https://trac.ffmpeg.org/query?status=new=open=reopened=~7.0 will list all blocking issues Ive added one, for testing that, i intend to add more if i see something What is blocking? (IMHO) * regressions (unless its non possible to fix before release) * crashes * security issues * data loss * privacy issues * anything the commuity agrees should be in the release We still have 3 blocking issues on trac do people want me to wait or ignore them and branch ? I think you can branch soon. However, those 3 bugs are quite important, tbh. The bump and the AVOption changes were already applied, so IMO we can branch. The two remaining issues should not be blocking as they can be backported to 7.0 in a point release. ___ 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".
Re: [FFmpeg-devel] [PATCH] avformat/aea: Add aea muxer
Thank you for your incredibly thorough and fast response. I've applied all the
corrections you requested. Please let me know if there's anything else wrong
with my patch, and thank you for your time.
- asivery
On Friday, March 8th, 2024 at 1:06 PM, Andreas Rheinhardt
wrote:
> asivery via ffmpeg-devel:
>
> > +typedef struct {
> > + int block_count;
> > +} AeaMuxerContext;
> > +
> > +static int aea_init(AVFormatContext *s)
> > +{
> > + AeaMuxerContext *c = s->priv_data;
> > + c->block_count = 0;
>
>
> Unnecessary: A muxer's priv_data is always pre-zeroed.
>
> > +
> > + return 0;
> > +}
> > +
> > +static int aea_write_header(AVFormatContext *s)
> > +{
> > + AVDictionaryEntry *title_entry;
>
>
> const
>
> > + int title_length = 0, i;
> > + char* title_contents;
> > + AVStream *st;
> > +
> > +
> > + if (s->nb_streams > 1) {
> > + av_log(s, AV_LOG_WARNING, "Got more than one stream to encode, they will
> > be ignored.\n");
>
>
> We don't ignore extraneous streams, we normally error out if something
> like this happens.
>
> > + }
> > +
> > + st = s->streams[0];
> > + if (st->codecpar->ch_layout.nb_channels != 1 &&
> > st->codecpar->ch_layout.nb_channels != 2) {
> > + av_log(s, AV_LOG_ERROR, "Invalid amount of channels to mux (%d).\n",
> > st->codecpar->ch_layout.nb_channels);
> > + return AVERROR(EINVAL);
> > + }
> > +
> > + if (st->codecpar->sample_rate != 44100) {
> > + av_log(s, AV_LOG_ERROR, "Invalid sample rate (%d) AEA only supports
> > 44.1kHz.\n", st->codecpar->sample_rate);
> > + return AVERROR(EINVAL);
> > + }
> > +
> > + /* Write magic /
> > + avio_wl32(s->pb, 2048);
> > +
> > + / Write AEA title */
> > + title_entry = av_dict_get(st->metadata, "title", NULL, 0);
> > + if (title_entry) {
> > + title_contents = title_entry->value;
> > + title_length = FFMIN(256, strlen(title_contents));
>
>
> Don't use strlen() in FFMIN (like many macros, it can evaluate its
> argument multiple times).
>
> > + }
> > +
> > + if (title_length) {
> > + avio_write(s->pb, title_contents, title_length);
> > + }
>
>
> No need for this branch, just call this inside the "if (title_entry)"
> block above.
>
> > +
> > + for (i = 0; i<(256 - title_length); i++) {
> > + avio_w8(s->pb, 0);
> > + }
>
>
> ffio_fill(). Same below.
>
> > +
> > + /* Write number of frames (zero at header-writing time, will seek later),
> > number of channels /
> > + avio_wl32(s->pb, 0);
> > + avio_w8(s->pb, st->codecpar->ch_layout.nb_channels);
> > + avio_w8(s->pb, 0);
> > +
> > + / Write flags (meaning unknown) /
> > + for(i = 0; i<11; i++) {
> > + avio_wl32(s->pb, 0);
> > + }
> > +
> > + / Pad the header to 2048 bytes */
> > + for(i = 0; i<1738; i++) avio_w8(s->pb, 0);
> > +
> > + return 0;
> > +}
> > +
> > +static int aea_write_packet(struct AVFormatContext *s, AVPacket *pkt)
> > +{
> > + AeaMuxerContext *c = s->priv_data;
> > + c->block_count++;
> > +
> > + avio_write(s->pb, pkt->data, pkt->size);
> > + return 0;
>
>
> You can avoid this and the whole muxer context by using
> ff_raw_write_packet() and relying on AVStream.nb_frames.
>
> > +}
> > +
> > +static int aea_write_trailer(struct AVFormatContext *s)
> > +{
> > + AVIOContext *pb = s->pb;
> > + AeaMuxerContext c = s->priv_data;
> > + if (pb->seekable & AVIO_SEEKABLE_NORMAL) {
> > + / Seek to rewrite the block count. */
> > + avio_seek(pb, 260, SEEK_SET);
> > + avio_wl32(pb, c->block_count *
> > s->streams[0]->codecpar->ch_layout.nb_channels);
> > + } else {
> > + av_log(s, AV_LOG_WARNING, "unable to rewrite AEA header.\n");
> > + }
> > +
> > + return 0;
> > +}
> > +
> > +const FFOutputFormat ff_aea_muxer = {
> > + .p.name = "aea",
> > + .p.long_name = NULL_IF_CONFIG_SMALL("MD STUDIO audio"),
> > + .priv_data_size = sizeof(AeaMuxerContext),
> > + .p.extensions = "aea",
> > + .p.audio_codec = AV_CODEC_ID_ATRAC1,
> > + .init = aea_init,
> > +
> > + .write_header = aea_write_header,
> > + .write_packet = aea_write_packet,
> > + .write_trailer = aea_write_trailer,
> > + .p.flags = AVFMT_GENERIC_INDEX,
>
>
> Makes no sense for a muxer.
>
> > +};
>
>
> ___
> 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".From d2163e7d943a5ba53148aa73a813a28d346124a4 Mon Sep 17 00:00:00 2001
From: asivery
Date: Fri, 8 Mar 2024 14:45:02 +0100
Subject: [PATCH] avformat/aea: Add aea muxer
Signed-off-by: asivery
---
libavformat/Makefile| 3 +-
libavformat/{aea.c => aeadec.c} | 0
libavformat/aeaenc.c| 103
libavformat/allformats.c| 1 +
4 files changed, 106 insertions(+), 1 deletion(-)
rename libavformat/{aea.c => aeadec.c} (100%)
create mode 100644 libavformat/aeaenc.c
diff --git a/libavformat/Makefile b/libavformat/Makefile
index 8811a0ffc9..70d56f391f 100644
--- a/libavformat/Makefile
+++
Re: [FFmpeg-devel] [PATCH v2 1/4] avcodec/aom_film_grain: add AOM film grain synthesis
On Fri, 08 Mar 2024 10:31:28 -0300 James Almer wrote: > On 3/8/2024 10:21 AM, Niklas Haas wrote: > > From: Niklas Haas > > > > Implementation copied wholesale from dav1d, sans SIMD, under permissive > > license. This implementation was extensively verified to be bit-exact, > > so it serves as a much better starting point than trying to re-engineer > > this from scratch for no reason. (I also authored the original > > implementation in dav1d, so any "clean room" implementation would end up > > looking much the same, anyway) > > > > The notable changes I had to make while adapting this from the dav1d > > code-base to the FFmpeg codebase include: > > > > - reordering variable declarations to avoid triggering warnings > > - replacing several inline helpers by avutil equivalents > > - changing code that accesses frame metadata > > - replacing raw plane copying logic by av_image_copy_plane > > > > Apart from this, the implementation is basically unmodified. > > Do we want this to be public? Both as a struct and the decoding functions. > It could be used by libavfilter or even outside our libraries. The hevc > decoder would export the relevant T.35 SEI in the new struct if told to > not apply fg, like we already do in av1. I'm not sure if the AFGS1 struct itself needs to be public, since it is largely just a codec-internal wrapper for multiple param sets (for scalable codecs). If we want to add a public film grain synthesis helper, IMHO it should be a wrapper around both ff_aom_apply_film_grain *and* ff_h274_apply_film_grain, which directly ingests an AVFilmGrainParams and resolves to the correct implementation. So we can merge this series as-is and still add a public helper on top. Incidentally, there is a strong precedent here: dav1d.h exports dav1d_apply_grain() precisely for the reason that VLC needs to initialize the decoder *before* it knows whether to apply synthesis on GPU or CPU, so it has to set the equivalent of `-export_side_data film_grain` at init time and manually apply CPU film grain synthesis if it turns out that GPU fgs is unavailable. ___ 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".
Re: [FFmpeg-devel] [PATCH] fate/flvenc: force the av1 decoder in all steps for fate-enhanced-flv-av1
James Almer 于2024年3月8日周五 21:19写道：
>
> Signed-off-by: James Almer
> ---
> tests/fate-run.sh | 5 +++--
> tests/fate/flvenc.mak | 2 +-
> tests/fate/mpegps.mak | 2 +-
> 3 files changed, 5 insertions(+), 4 deletions(-)
>
> diff --git a/tests/fate-run.sh b/tests/fate-run.sh
> index 2de560354f..0fead78c58 100755
> --- a/tests/fate-run.sh
> +++ b/tests/fate-run.sh
> @@ -292,14 +292,15 @@ stream_remux(){
> enc_fmt=$4
> stream_maps=$5
> final_decode=$6
> -ffprobe_opts=$7
> +final_encode=$7
> +ffprobe_opts=$8
> encfile="${outdir}/${test}.${enc_fmt}"
> test $keep -ge 1 || cleanfiles="$cleanfiles $encfile"
> tsrcfile=$(target_path $srcfile)
> tencfile=$(target_path $encfile)
> ffmpeg -f $src_fmt $src_opts -i $tsrcfile $stream_maps -codec copy
> $FLAGS \
> -f $enc_fmt -y $tencfile || return
> -ffmpeg $DEC_OPTS -i $tencfile $ENC_OPTS $FLAGS $final_decode \
> +ffmpeg $DEC_OPTS $final_decode -i $tencfile $ENC_OPTS $FLAGS
> $final_encode \
> -f framecrc - || return
> test -z "$ffprobe_opts" || \
> run ffprobe${PROGSUF}${EXECSUF} -bitexact $ffprobe_opts $tencfile ||
> return
> diff --git a/tests/fate/flvenc.mak b/tests/fate/flvenc.mak
> index 3cfe930e43..e3703a8cc5 100644
> --- a/tests/fate/flvenc.mak
> +++ b/tests/fate/flvenc.mak
> @@ -11,7 +11,7 @@ fate-enhanced-flv-vp9: CMD = transcode ivf
> $(TARGET_SAMPLES)/vp9-test-vectors/vp
>
> FATE_ENHANCED_FLVENC_FFMPEG-$(call REMUX, FLV IVF, FLV_DEMUXER AV1_DECODER
> AV1_PARSER) += fate-enhanced-flv-av1
> fate-enhanced-flv-av1: CMD = stream_remux ivf
> $(TARGET_SAMPLES)/av1/seq_hdr_op_param_info.ivf "-c:v av1" \
> - flv "-c copy" "-c copy"
> + flv "-c copy" "-c:v av1" "-c copy"
>
> FATE_FFMPEG_FFPROBE += $(FATE_FLVENC_FFMPEG_FFPROBE-yes)
> FATE_SAMPLES_FFMPEG += $(FATE_ENHANCED_FLVENC_FFMPEG-yes)
> diff --git a/tests/fate/mpegps.mak b/tests/fate/mpegps.mak
> index ae301fd5e1..43cd2aa22b 100644
> --- a/tests/fate/mpegps.mak
> +++ b/tests/fate/mpegps.mak
> @@ -1,7 +1,7 @@
> # This tests that a 16-bit pcm_dvd stream is correctly remuxed in mpegps
> FATE_MPEGPS-$(call DEMMUX, MPEGPS, MPEG1SYSTEM) +=
> fate-mpegps-remuxed-pcm-demux
> fate-mpegps-remuxed-pcm-demux: $(SAMPLES)/mpegps/pcm_aud.mpg
> -fate-mpegps-remuxed-pcm-demux: CMD = stream_remux "mpeg"
> "$(TARGET_SAMPLES)/mpegps/pcm_aud.mpg" "" "mpeg" "-map 0:a:0" "-codec copy"
> +fate-mpegps-remuxed-pcm-demux: CMD = stream_remux "mpeg"
> "$(TARGET_SAMPLES)/mpegps/pcm_aud.mpg" "" "mpeg" "-map 0:a:0" "" "-codec copy"
>
> FATE_SAMPLES_FFMPEG += $(FATE_MPEGPS-yes)
> fate-mpegps: $(FATE_MPEGPS-yes)
> --
> 2.44.0
>
> ___
> 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".
Tested ok now.
Thanks
Steven
___
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".
Re: [FFmpeg-devel] [PATCH] avcodec/libaomdec: decode extradata in aom_init
James Almer 于2024年3月8日周五 21:13写道：
>
> On 3/8/2024 10:07 AM, Andreas Rheinhardt wrote:
> > Steven Liu:
> >> before patch:
> >> test failed when using libaomdec.
> >> TESTenhanced-flv-av1
> >> --- src/tests/ref/fate/enhanced-flv-av1 2024-03-08 11:27:13.577935587
> >> +0800
> >> +++ tests/data/fate/enhanced-flv-av1 2024-03-08 17:38:25.810152322 +0800
> >> @@ -3,7 +3,7 @@
> >> #media_type 0: video
> >> #codec_id 0: av1
> >> #dimensions 0: 320x176
> >> -#sar 0: 0/1
> >> +#sar 0: 1/1
> >> 0, 0, 0, 41, 4718, 0xc4d912ec
> >> 0, 42, 42, 41, 5109, 0xc065dd7d, F=0x0
> >> 0, 83, 83, 41, 192, 0x160c5335, F=0x0
> >>
> >> after patch:
> >> test passed
> >>
> >> Signed-off-by: Steven Liu
> >> ---
> >> libavcodec/libaomdec.c | 12
> >> 1 file changed, 12 insertions(+)
> >>
> >> diff --git a/libavcodec/libaomdec.c b/libavcodec/libaomdec.c
> >> index 69eec8b089..2df2fa6fd7 100644
> >> --- a/libavcodec/libaomdec.c
> >> +++ b/libavcodec/libaomdec.c
> >> @@ -58,6 +58,18 @@ static av_cold int aom_init(AVCodecContext *avctx,
> >> return AVERROR(EINVAL);
> >> }
> >>
> >> +if (aom_codec_decode(>decoder, avctx->extradata,
> >> avctx->extradata_size,
> >> + NULL) != AOM_CODEC_OK) {
> >> +const char *error = aom_codec_error(>decoder);
> >> +const char *detail = aom_codec_error_detail(>decoder);
> >> +
> >> +av_log(avctx, AV_LOG_ERROR, "Failed to decode extradata: %s\n",
> >> error);
> >> +if (detail)
> >> +av_log(avctx, AV_LOG_ERROR, " Additional information: %s\n",
> >> detail);
> >> +
> >> +return AVERROR(EINVAL);
> >> +}
> >> +
> >> return 0;
> >> }
> >>
> >
> > This patch is very problematic: If you change the ref file to match
> > libaomdec, it will be broken for those that use other decoders than
> > libaomdec. Actually, there should be no reason to use libaomdec for
> > probing since 194414f62d987ad831654c45fff6ee27898b832e. Maybe we should
> > add the AVOID_PROBING cap to the other AV1 decoders in case the native
> > one is available?
>
> Or add -c:v av1 as input argument for the final decode in stream_remux()
> from fate-run.sh
It's using -c:v av1 right now, or should I move libavformat/av1.c to
libavcodec and modify for support set the params?
Thanks
Steven
___
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".
Re: [FFmpeg-devel] [PATCH 2/3] lavc: replace ff_thread_get_buffer() with ff_get_buffer()
On Fri, Mar 8, 2024 at 2:20 PM Nicolas George wrote: > Andreas Rheinhardt (12024-03-08): > > What maintenance cost and complexity are you referring to? I checked and > > could not find a single commit where one had to fix an ff_get_buffer() > > to ff_thread_get_buffer() because it has been forgotten when the decoder > > has been declared to support frame threading. > > Welcome to the new FFmpeg, where absolute consistency, i.e. catering for > hypothetical mediocre contributors, is more important than easy > optimizations and new approaches. > > And if you do not like it, “shut up, I'm on the TC and I won't recuse”. > > And if you do not like that, “shut up, I'm on the CC too”. > Is this first time I 100% agree on something with my archenemy? > > Regards, > > -- > Nicolas George > ___ > 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". > ___ 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".
Re: [FFmpeg-devel] [PATCH v2 2/4] avcodec/aom_film_grain: implement AFGS1
On Fri, 08 Mar 2024 14:21:06 +0100 Niklas Haas wrote: > From: Niklas Haas > > Changes from v1: > - fixed interpretation of num_sets_minus1 (missing +1) Also removed the 'Note:' from the commit message, as I have received clarification from the spec authors confirming that our implementation was the correct interpretation. ___ 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".
[FFmpeg-devel] [PATCH v2 4/4] avcodec/hevcdec: apply AOM film grain synthesis
From: Niklas Haas
Following the usual logic for H.274 film grain.
---
libavcodec/Makefile | 2 +-
libavcodec/hevcdec.c | 24
2 files changed, 21 insertions(+), 5 deletions(-)
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index 68e5394d84e..67faf620742 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -432,7 +432,7 @@ OBJS-$(CONFIG_HDR_ENCODER) += hdrenc.o
OBJS-$(CONFIG_HEVC_DECODER)+= hevcdec.o hevc_mvs.o \
hevc_cabac.o hevc_refs.o hevcpred.o
\
hevcdsp.o hevc_filter.o hevc_data.o \
- h274.o
+ h274.o aom_film_grain.o
OBJS-$(CONFIG_HEVC_AMF_ENCODER)+= amfenc_hevc.o
OBJS-$(CONFIG_HEVC_CUVID_DECODER) += cuviddec.o
OBJS-$(CONFIG_HEVC_MEDIACODEC_DECODER) += mediacodecdec.o
diff --git a/libavcodec/hevcdec.c b/libavcodec/hevcdec.c
index 76aa6b45882..2809be659a8 100644
--- a/libavcodec/hevcdec.c
+++ b/libavcodec/hevcdec.c
@@ -35,6 +35,7 @@
#include "libavutil/pixdesc.h"
#include "libavutil/timecode.h"
+#include "aom_film_grain.h"
#include "bswapdsp.h"
#include "cabac_functions.h"
#include "codec_internal.h"
@@ -388,7 +389,8 @@ static int export_stream_params_from_sei(HEVCContext *s)
avctx->color_trc =
s->sei.common.alternative_transfer.preferred_transfer_characteristics;
}
-if (s->sei.common.film_grain_characteristics.present)
+if (s->sei.common.film_grain_characteristics.present ||
+s->sei.common.aom_film_grain.enable)
avctx->properties |= FF_CODEC_PROPERTY_FILM_GRAIN;
return 0;
@@ -2885,11 +2887,13 @@ static int hevc_frame_start(HEVCContext *s)
else
s->ref->frame->flags &= ~AV_FRAME_FLAG_KEY;
-s->ref->needs_fg = s->sei.common.film_grain_characteristics.present &&
+s->ref->needs_fg = (s->sei.common.film_grain_characteristics.present ||
+s->sei.common.aom_film_grain.enable) &&
!(s->avctx->export_side_data & AV_CODEC_EXPORT_DATA_FILM_GRAIN) &&
!s->avctx->hwaccel;
if (s->ref->needs_fg &&
+s->sei.common.film_grain_characteristics.present &&
!ff_h274_film_grain_params_supported(s->sei.common.film_grain_characteristics.model_id,
s->ref->frame->format)) {
av_log_once(s->avctx, AV_LOG_WARNING, AV_LOG_DEBUG,
>film_grain_warning_shown,
@@ -2935,13 +2939,24 @@ static int hevc_frame_end(HEVCContext *s)
{
HEVCFrame *out = s->ref;
const AVFrameSideData *sd;
+const AVFilmGrainParams *fgp;
av_unused int ret;
if (out->needs_fg) {
sd = av_frame_get_side_data(out->frame,
AV_FRAME_DATA_FILM_GRAIN_PARAMS);
av_assert0(out->frame_grain->buf[0] && sd);
-ret = ff_h274_apply_film_grain(out->frame_grain, out->frame,
>h274db,
- (AVFilmGrainParams *) sd->data);
+fgp = (AVFilmGrainParams *) sd->data;
+switch (fgp->type) {
+case AV_FILM_GRAIN_PARAMS_NONE:
+return AVERROR_BUG; /* impossible, SD should not be present */
+case AV_FILM_GRAIN_PARAMS_H274:
+ret = ff_h274_apply_film_grain(out->frame_grain, out->frame,
+ >h274db, fgp);
+break;
+case AV_FILM_GRAIN_PARAMS_AV1:
+ret = ff_aom_apply_film_grain(out->frame_grain, out->frame, fgp);
+break;
+}
av_assert1(ret >= 0);
}
@@ -3596,6 +3611,7 @@ static int hevc_update_thread_context(AVCodecContext *dst,
s->sei.common.alternative_transfer = s0->sei.common.alternative_transfer;
s->sei.common.mastering_display= s0->sei.common.mastering_display;
s->sei.common.content_light= s0->sei.common.content_light;
+s->sei.common.aom_film_grain = s0->sei.common.aom_film_grain;
ret = export_stream_params_from_sei(s);
if (ret < 0)
--
2.44.0
___
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".
[FFmpeg-devel] [PATCH v2 3/4] avcodec/h2645_sei: decode AFGS1 T.35 SEI
From: Niklas Haas
Changes from v1:
- fixed field size of provider_oriented_code (8 instead of 16 bits)
---
I restricted this SEI to HEVC for now, until I see a H.264 sample.
---
libavcodec/Makefile| 2 +-
libavcodec/h2645_sei.c | 38 ++
libavcodec/h2645_sei.h | 3 +++
3 files changed, 42 insertions(+), 1 deletion(-)
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index 5d99120aa91..68e5394d84e 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -105,7 +105,7 @@ OBJS-$(CONFIG_H264_SEI)+= h264_sei.o
h2645_sei.o
OBJS-$(CONFIG_HEVCPARSE) += hevc_parse.o hevc_ps.o hevc_data.o \
h2645data.o h2645_parse.o h2645_vui.o
OBJS-$(CONFIG_HEVC_SEI)+= hevc_sei.o h2645_sei.o \
- dynamic_hdr_vivid.o
+ dynamic_hdr_vivid.o aom_film_grain.o
OBJS-$(CONFIG_HPELDSP) += hpeldsp.o
OBJS-$(CONFIG_HUFFMAN) += huffman.o
OBJS-$(CONFIG_HUFFYUVDSP) += huffyuvdsp.o
diff --git a/libavcodec/h2645_sei.c b/libavcodec/h2645_sei.c
index e60606f43f9..d6452e8fbfa 100644
--- a/libavcodec/h2645_sei.c
+++ b/libavcodec/h2645_sei.c
@@ -209,6 +209,24 @@ static int decode_registered_user_data(H2645SEI *h,
GetByteContext *gb,
}
break;
}
+case 0x5890: { // aom_provider_code
+const uint16_t aom_grain_provider_oriented_code = 0x0001;
+uint16_t provider_oriented_code;
+
+if (!IS_HEVC(codec_id))
+goto unsupported_provider_code;
+
+if (bytestream2_get_bytes_left(gb) < 2)
+return AVERROR_INVALIDDATA;
+
+provider_oriented_code = bytestream2_get_byteu(gb);
+if (provider_oriented_code == aom_grain_provider_oriented_code) {
+return ff_aom_parse_film_grain_sets(>aom_film_grain,
+gb->buffer,
+
bytestream2_get_bytes_left(gb));
+}
+break;
+}
unsupported_provider_code:
#endif
default:
@@ -692,6 +710,25 @@ int ff_h2645_sei_to_frame(AVFrame *frame, H2645SEI *sei,
avctx->properties |= FF_CODEC_PROPERTY_FILM_GRAIN;
}
+#if CONFIG_HEVC_SEI
+if (sei->aom_film_grain.enable) {
+const AVFilmGrainAOMParamSet *fgps;
+fgps = ff_aom_select_film_grain_set(>aom_film_grain, frame);
+if (fgps && fgps->apply_grain) {
+AVFilmGrainParams *fgp =
av_film_grain_params_create_side_data(frame);
+if (!fgp)
+return AVERROR(ENOMEM);
+
+fgp->type = AV_FILM_GRAIN_PARAMS_AV1;
+fgp->seed = fgps->grain_seed;
+fgp->codec.aom = fgps->params;
+
+if (avctx)
+avctx->properties |= FF_CODEC_PROPERTY_FILM_GRAIN;
+}
+}
+#endif
+
if (sei->ambient_viewing_environment.present) {
H2645SEIAmbientViewingEnvironment *env =
>ambient_viewing_environment;
@@ -788,4 +825,5 @@ void ff_h2645_sei_reset(H2645SEI *s)
s->ambient_viewing_environment.present = 0;
s->mastering_display.present = 0;
s->content_light.present = 0;
+s->aom_film_grain.enable = 0;
}
diff --git a/libavcodec/h2645_sei.h b/libavcodec/h2645_sei.h
index 0ebf48011af..e5fcfd4e0c2 100644
--- a/libavcodec/h2645_sei.h
+++ b/libavcodec/h2645_sei.h
@@ -23,7 +23,9 @@
#include "libavutil/buffer.h"
#include "libavutil/frame.h"
+#include "libavutil/film_grain_params.h"
+#include "aom_film_grain.h"
#include "avcodec.h"
#include "bytestream.h"
#include "codec_id.h"
@@ -132,6 +134,7 @@ typedef struct H2645SEI {
H2645SEIAmbientViewingEnvironment ambient_viewing_environment;
H2645SEIMasteringDisplay mastering_display;
H2645SEIContentLight content_light;
+AVFilmGrainAOMParamSets aom_film_grain;
} H2645SEI;
enum {
--
2.44.0
___
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".
[FFmpeg-devel] [PATCH v2 2/4] avcodec/aom_film_grain: implement AFGS1
From: Niklas Haas
Changes from v1:
- fixed interpretation of num_sets_minus1 (missing +1)
---
Based on the AOMedia Film Grain Synthesis 1 (AFGS1) spec:
https://aomediacodec.github.io/afgs1-spec/
The parsing has been changed substantially relative to the AV1 film
grain OBU. In particular:
1. There is the possibility of maintaining multiple independent film
grain parameter sets, and decoders are recommended to pick the one
most appropriate for the intended display resolution. This is to
support scalable / multi-level codecs, although this could also be
used to e.g. switch between different grain profiles without having
to re-signal the appropriate coefficients.
2. Supporting this, it's possible to *predict* the grain coefficients
from previously signalled parameter sets, transmitting only the
residual.
3. When not predicting, the parameter sets are now stored as a series of
increments, rather than being directly transmitted.
I placed this parser in its own file, rather than h2645_sei.c, since
nothing in the generic AFGS1 film grain payload is specific to T.35.
---
libavcodec/aom_film_grain.c | 227
libavcodec/aom_film_grain.h | 25
2 files changed, 252 insertions(+)
diff --git a/libavcodec/aom_film_grain.c b/libavcodec/aom_film_grain.c
index ffcd71b584b..edea2758d3c 100644
--- a/libavcodec/aom_film_grain.c
+++ b/libavcodec/aom_film_grain.c
@@ -29,6 +29,7 @@
#include "libavutil/imgutils.h"
#include "aom_film_grain.h"
+#include "get_bits.h"
// Common/shared helpers (not dependent on BIT_DEPTH)
static inline int get_random_number(const int bits, unsigned *const state) {
@@ -118,6 +119,232 @@ int ff_aom_apply_film_grain(AVFrame *out, const AVFrame
*in,
return AVERROR_INVALIDDATA;
}
+int ff_aom_parse_film_grain_sets(AVFilmGrainAOMParamSets *s,
+ const uint8_t *payload, int payload_size)
+{
+GetBitContext gbc, *gb =
+AVFilmGrainAOMParams *aom;
+AVFilmGrainAOMParamSet *fgps, *ref = NULL;
+int ret, num_sets, n, i, uv, num_y_coeffs, update_grain, luma_only;
+
+ret = init_get_bits8(gb, payload, payload_size);
+if (ret < 0)
+return ret;
+
+s->enable = get_bits1(gb);
+if (!s->enable)
+return 0;
+
+skip_bits(gb, 4); // reserved
+num_sets = get_bits(gb, 3) + 1;
+for (n = 0; n < num_sets; n++) {
+int payload_4byte, payload_size, set_idx, apply_units_log2, vsc_flag;
+int predict_scaling, predict_y_scaling, predict_uv_scaling[2];
+int payload_bits, start_position;
+
+start_position = get_bits_count(gb);
+payload_4byte = get_bits1(gb);
+payload_size = get_bits(gb, payload_4byte ? 2 : 8);
+set_idx = get_bits(gb, 3);
+fgps = >sets[set_idx];
+
+fgps->apply_grain = get_bits1(gb);
+if (!fgps->apply_grain)
+continue;
+
+fgps->grain_seed = get_bits(gb, 16);
+update_grain = get_bits1(gb);
+if (!update_grain)
+continue;
+
+apply_units_log2 = get_bits(gb, 4);
+fgps->apply_width = get_bits(gb, 12) << apply_units_log2;
+fgps->apply_height = get_bits(gb, 12) << apply_units_log2;
+luma_only = get_bits1(gb);
+if (luma_only) {
+fgps->subx = fgps->suby = 0;
+} else {
+fgps->subx = get_bits1(gb);
+fgps->suby = get_bits1(gb);
+}
+
+vsc_flag = get_bits1(gb); // video_signal_characteristics_flag
+if (vsc_flag) {
+int cicp_flag;
+skip_bits(gb, 3); // bit_depth_minus8
+cicp_flag = get_bits1(gb);
+if (cicp_flag)
+skip_bits(gb, 8 + 8 + 8 + 1); // cicp_info
+}
+
+aom = >params;
+predict_scaling = get_bits1(gb);
+if (predict_scaling && (!ref || ref == fgps))
+goto error; // prediction must be from valid, different set
+
+predict_y_scaling = predict_scaling ? get_bits1(gb) : 0;
+if (predict_y_scaling) {
+int y_scale, y_offset, bits_res;
+y_scale = get_bits(gb, 9) - 256;
+y_offset = get_bits(gb, 9) - 256;
+bits_res = get_bits(gb, 3);
+if (bits_res) {
+int res[14], pred, granularity;
+aom->num_y_points = ref->params.num_y_points;
+for (i = 0; i < aom->num_y_points; i++)
+res[i] = get_bits(gb, bits_res);
+granularity = get_bits(gb, 3);
+for (i = 0; i < aom->num_y_points; i++) {
+pred = ref->params.y_points[i][1];
+pred = ((pred * y_scale + 8) >> 4) + y_offset;
+pred += (res[i] - (1 << (bits_res - 1))) * granularity;
+aom->y_points[i][0] = ref->params.y_points[i][0];
+aom->y_points[i][1] = av_clip_uint8(pred);
+}
+}
+} else {
[FFmpeg-devel] [PATCH v2 1/4] avcodec/aom_film_grain: add AOM film grain synthesis
From: Niklas Haas
Implementation copied wholesale from dav1d, sans SIMD, under permissive
license. This implementation was extensively verified to be bit-exact,
so it serves as a much better starting point than trying to re-engineer
this from scratch for no reason. (I also authored the original
implementation in dav1d, so any "clean room" implementation would end up
looking much the same, anyway)
The notable changes I had to make while adapting this from the dav1d
code-base to the FFmpeg codebase include:
- reordering variable declarations to avoid triggering warnings
- replacing several inline helpers by avutil equivalents
- changing code that accesses frame metadata
- replacing raw plane copying logic by av_image_copy_plane
Apart from this, the implementation is basically unmodified.
---
libavcodec/aom_film_grain.c | 310 ++
libavcodec/aom_film_grain.h | 38 ++
libavcodec/aom_film_grain_template.c | 577 +++
3 files changed, 925 insertions(+)
create mode 100644 libavcodec/aom_film_grain.c
create mode 100644 libavcodec/aom_film_grain.h
create mode 100644 libavcodec/aom_film_grain_template.c
diff --git a/libavcodec/aom_film_grain.c b/libavcodec/aom_film_grain.c
new file mode 100644
index 000..ffcd71b584b
--- /dev/null
+++ b/libavcodec/aom_film_grain.c
@@ -0,0 +1,310 @@
+/*
+ * AOM film grain synthesis
+ * Copyright (c) 2023 Niklas Haas
+ *
+ * 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 Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+/**
+ * @file
+ * AOM film grain synthesis.
+ * @author Niklas Haas
+ */
+
+#include "libavutil/avassert.h"
+#include "libavutil/imgutils.h"
+
+#include "aom_film_grain.h"
+
+// Common/shared helpers (not dependent on BIT_DEPTH)
+static inline int get_random_number(const int bits, unsigned *const state) {
+const int r = *state;
+unsigned bit = ((r >> 0) ^ (r >> 1) ^ (r >> 3) ^ (r >> 12)) & 1;
+*state = (r >> 1) | (bit << 15);
+
+return (*state >> (16 - bits)) & ((1 << bits) - 1);
+}
+
+static inline int round2(const int x, const uint64_t shift) {
+return (x + ((1 << shift) >> 1)) >> shift;
+}
+
+enum {
+GRAIN_WIDTH = 82,
+GRAIN_HEIGHT = 73,
+SUB_GRAIN_WIDTH = 44,
+SUB_GRAIN_HEIGHT = 38,
+FG_BLOCK_SIZE= 32,
+};
+
+static const int16_t gaussian_sequence[2048];
+
+#define BIT_DEPTH 16
+#include "aom_film_grain_template.c"
+#undef BIT_DEPTH
+
+#define BIT_DEPTH 8
+#include "aom_film_grain_template.c"
+#undef BIT_DEPTH
+
+
+int ff_aom_apply_film_grain(AVFrame *out, const AVFrame *in,
+const AVFilmGrainParams *params)
+{
+const AVFilmGrainAOMParams *const data = >codec.aom;
+const AVPixFmtDescriptor *desc = av_pix_fmt_desc_get(out->format);
+const int subx = desc->log2_chroma_w, suby = desc->log2_chroma_h;
+const int pxstep = desc->comp[0].step;
+
+av_assert0(out->format == in->format);
+av_assert0(params->type == AV_FILM_GRAIN_PARAMS_AV1);
+
+// Copy over the non-modified planes
+if (!params->codec.aom.num_y_points) {
+av_image_copy_plane(out->data[0], out->linesize[0],
+in->data[0], in->linesize[0],
+out->width * pxstep, out->height);
+}
+for (int uv = 0; uv < 2; uv++) {
+if (!data->num_uv_points[uv]) {
+av_image_copy_plane(out->data[1+uv], out->linesize[1+uv],
+in->data[1+uv], in->linesize[1+uv],
+AV_CEIL_RSHIFT(out->width, subx) * pxstep,
+AV_CEIL_RSHIFT(out->height, suby));
+}
+}
+
+switch (in->format) {
+case AV_PIX_FMT_GRAY8:
+case AV_PIX_FMT_YUV420P:
+case AV_PIX_FMT_YUV422P:
+case AV_PIX_FMT_YUV444P:
+case AV_PIX_FMT_YUVJ420P:
+case AV_PIX_FMT_YUVJ422P:
+case AV_PIX_FMT_YUVJ444P:
+return apply_film_grain_8(out, in, params);
+case AV_PIX_FMT_GRAY9:
+case AV_PIX_FMT_YUV420P9:
+case AV_PIX_FMT_YUV422P9:
+case AV_PIX_FMT_YUV444P9:
+return apply_film_grain_16(out, in, params, 9);
+case AV_PIX_FMT_GRAY10:
+case AV_PIX_FMT_YUV420P10:
+case AV_PIX_FMT_YUV422P10:
+case AV_PIX_FMT_YUV444P10:
+return apply_film_grain_16(out, in, params, 10);
+
Re: [FFmpeg-devel] [PATCH 2/3] lavc: replace ff_thread_get_buffer() with ff_get_buffer()
Andreas Rheinhardt (12024-03-08): > What maintenance cost and complexity are you referring to? I checked and > could not find a single commit where one had to fix an ff_get_buffer() > to ff_thread_get_buffer() because it has been forgotten when the decoder > has been declared to support frame threading. Welcome to the new FFmpeg, where absolute consistency, i.e. catering for hypothetical mediocre contributors, is more important than easy optimizations and new approaches. And if you do not like it, “shut up, I'm on the TC and I won't recuse”. And if you do not like that, “shut up, I'm on the CC too”. Regards, -- Nicolas George ___ 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".
[FFmpeg-devel] [PATCH] fate/flvenc: force the av1 decoder in all steps for fate-enhanced-flv-av1
Signed-off-by: James Almer
---
tests/fate-run.sh | 5 +++--
tests/fate/flvenc.mak | 2 +-
tests/fate/mpegps.mak | 2 +-
3 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/tests/fate-run.sh b/tests/fate-run.sh
index 2de560354f..0fead78c58 100755
--- a/tests/fate-run.sh
+++ b/tests/fate-run.sh
@@ -292,14 +292,15 @@ stream_remux(){
enc_fmt=$4
stream_maps=$5
final_decode=$6
-ffprobe_opts=$7
+final_encode=$7
+ffprobe_opts=$8
encfile="${outdir}/${test}.${enc_fmt}"
test $keep -ge 1 || cleanfiles="$cleanfiles $encfile"
tsrcfile=$(target_path $srcfile)
tencfile=$(target_path $encfile)
ffmpeg -f $src_fmt $src_opts -i $tsrcfile $stream_maps -codec copy $FLAGS \
-f $enc_fmt -y $tencfile || return
-ffmpeg $DEC_OPTS -i $tencfile $ENC_OPTS $FLAGS $final_decode \
+ffmpeg $DEC_OPTS $final_decode -i $tencfile $ENC_OPTS $FLAGS $final_encode
\
-f framecrc - || return
test -z "$ffprobe_opts" || \
run ffprobe${PROGSUF}${EXECSUF} -bitexact $ffprobe_opts $tencfile ||
return
diff --git a/tests/fate/flvenc.mak b/tests/fate/flvenc.mak
index 3cfe930e43..e3703a8cc5 100644
--- a/tests/fate/flvenc.mak
+++ b/tests/fate/flvenc.mak
@@ -11,7 +11,7 @@ fate-enhanced-flv-vp9: CMD = transcode ivf
$(TARGET_SAMPLES)/vp9-test-vectors/vp
FATE_ENHANCED_FLVENC_FFMPEG-$(call REMUX, FLV IVF, FLV_DEMUXER AV1_DECODER
AV1_PARSER) += fate-enhanced-flv-av1
fate-enhanced-flv-av1: CMD = stream_remux ivf
$(TARGET_SAMPLES)/av1/seq_hdr_op_param_info.ivf "-c:v av1" \
- flv "-c copy" "-c copy"
+ flv "-c copy" "-c:v av1" "-c copy"
FATE_FFMPEG_FFPROBE += $(FATE_FLVENC_FFMPEG_FFPROBE-yes)
FATE_SAMPLES_FFMPEG += $(FATE_ENHANCED_FLVENC_FFMPEG-yes)
diff --git a/tests/fate/mpegps.mak b/tests/fate/mpegps.mak
index ae301fd5e1..43cd2aa22b 100644
--- a/tests/fate/mpegps.mak
+++ b/tests/fate/mpegps.mak
@@ -1,7 +1,7 @@
# This tests that a 16-bit pcm_dvd stream is correctly remuxed in mpegps
FATE_MPEGPS-$(call DEMMUX, MPEGPS, MPEG1SYSTEM) +=
fate-mpegps-remuxed-pcm-demux
fate-mpegps-remuxed-pcm-demux: $(SAMPLES)/mpegps/pcm_aud.mpg
-fate-mpegps-remuxed-pcm-demux: CMD = stream_remux "mpeg"
"$(TARGET_SAMPLES)/mpegps/pcm_aud.mpg" "" "mpeg" "-map 0:a:0" "-codec copy"
+fate-mpegps-remuxed-pcm-demux: CMD = stream_remux "mpeg"
"$(TARGET_SAMPLES)/mpegps/pcm_aud.mpg" "" "mpeg" "-map 0:a:0" "" "-codec copy"
FATE_SAMPLES_FFMPEG += $(FATE_MPEGPS-yes)
fate-mpegps: $(FATE_MPEGPS-yes)
--
2.44.0
___
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".
Re: [FFmpeg-devel] [RFC] clarifying the TC conflict of interest rule
On Thu, Mar 7, 2024 at 3:01 PM Vittorio Giovara wrote: > On Thu, Mar 7, 2024 at 12:25 AM Michael Niedermayer via ffmpeg-devel < > ffmpeg-devel@ffmpeg.org> wrote: > > > > instead of backroom deals, for a > > > change. > > > > iam sorry, but these accusations are not acceptable > > The application was and is on a public wiki > > the SoWs where collected by pierre and it was publically announced > before. > > I tried to contact all people before the deadline who had incomplete > > submissions. > > > > I think the backroom deals is referring to the months of silence between > *some people* knowing and the community being informed, plus the rushed 2 > weeks voting time > > > > I think for a change you should say thanks to tara, pierre, SPI, STF and > > others > > doing all the work. Instead of accusations. > > > > I don't see anybody thanking Anton for the work trying to solve the > contentious point on the rules > If anything he keeps being disparaged by conspiracy theorists, and getting > the discussion derailed > > > > And you should submit a proposal with SoW and all needed information > > next time. Similarly others should too. The idea of this was never to > have > > just 2 people submit SoWs > > > > > > > > > > The application has apparently been submitted, with no public > > > announcement that it even happened, much less what was in it. > > > > whats in it, should simlpy be what was on the wiki application > > plus the fixes and cleanups mentioned above > > > > Can you guys open a separate thread for these points? They have nothing to > do with the case at hand. > Thanks for confirming complete lack of transparency on all aspects in this undead project. > -- > Vittorio > ___ > 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". > ___ 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".
Re: [FFmpeg-devel] [PATCH] avcodec/libaomdec: decode extradata in aom_init
On 3/8/2024 10:07 AM, Andreas Rheinhardt wrote:
Steven Liu:
before patch:
test failed when using libaomdec.
TESTenhanced-flv-av1
--- src/tests/ref/fate/enhanced-flv-av1 2024-03-08 11:27:13.577935587 +0800
+++ tests/data/fate/enhanced-flv-av12024-03-08 17:38:25.810152322 +0800
@@ -3,7 +3,7 @@
#media_type 0: video
#codec_id 0: av1
#dimensions 0: 320x176
-#sar 0: 0/1
+#sar 0: 1/1
0, 0, 0, 41, 4718, 0xc4d912ec
0, 42, 42, 41, 5109, 0xc065dd7d, F=0x0
0, 83, 83, 41, 192, 0x160c5335, F=0x0
after patch:
test passed
Signed-off-by: Steven Liu
---
libavcodec/libaomdec.c | 12
1 file changed, 12 insertions(+)
diff --git a/libavcodec/libaomdec.c b/libavcodec/libaomdec.c
index 69eec8b089..2df2fa6fd7 100644
--- a/libavcodec/libaomdec.c
+++ b/libavcodec/libaomdec.c
@@ -58,6 +58,18 @@ static av_cold int aom_init(AVCodecContext *avctx,
return AVERROR(EINVAL);
}
+if (aom_codec_decode(>decoder, avctx->extradata, avctx->extradata_size,
+ NULL) != AOM_CODEC_OK) {
+const char *error = aom_codec_error(>decoder);
+const char *detail = aom_codec_error_detail(>decoder);
+
+av_log(avctx, AV_LOG_ERROR, "Failed to decode extradata: %s\n", error);
+if (detail)
+av_log(avctx, AV_LOG_ERROR, " Additional information: %s\n",
detail);
+
+return AVERROR(EINVAL);
+}
+
return 0;
}
This patch is very problematic: If you change the ref file to match
libaomdec, it will be broken for those that use other decoders than
libaomdec. Actually, there should be no reason to use libaomdec for
probing since 194414f62d987ad831654c45fff6ee27898b832e. Maybe we should
add the AVOID_PROBING cap to the other AV1 decoders in case the native
one is available?
Or add -c:v av1 as input argument for the final decode in stream_remux()
from fate-run.sh
___
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".
Re: [FFmpeg-devel] [PATCH] avcodec/libaomdec: decode extradata in aom_init
Steven Liu:
> before patch:
> test failed when using libaomdec.
> TESTenhanced-flv-av1
> --- src/tests/ref/fate/enhanced-flv-av1 2024-03-08 11:27:13.577935587
> +0800
> +++ tests/data/fate/enhanced-flv-av1 2024-03-08 17:38:25.810152322 +0800
> @@ -3,7 +3,7 @@
> #media_type 0: video
> #codec_id 0: av1
> #dimensions 0: 320x176
> -#sar 0: 0/1
> +#sar 0: 1/1
> 0, 0, 0, 41, 4718, 0xc4d912ec
> 0, 42, 42, 41, 5109, 0xc065dd7d, F=0x0
> 0, 83, 83, 41, 192, 0x160c5335, F=0x0
>
> after patch:
> test passed
>
> Signed-off-by: Steven Liu
> ---
> libavcodec/libaomdec.c | 12
> 1 file changed, 12 insertions(+)
>
> diff --git a/libavcodec/libaomdec.c b/libavcodec/libaomdec.c
> index 69eec8b089..2df2fa6fd7 100644
> --- a/libavcodec/libaomdec.c
> +++ b/libavcodec/libaomdec.c
> @@ -58,6 +58,18 @@ static av_cold int aom_init(AVCodecContext *avctx,
> return AVERROR(EINVAL);
> }
>
> +if (aom_codec_decode(>decoder, avctx->extradata,
> avctx->extradata_size,
> + NULL) != AOM_CODEC_OK) {
> +const char *error = aom_codec_error(>decoder);
> +const char *detail = aom_codec_error_detail(>decoder);
> +
> +av_log(avctx, AV_LOG_ERROR, "Failed to decode extradata: %s\n",
> error);
> +if (detail)
> +av_log(avctx, AV_LOG_ERROR, " Additional information: %s\n",
> detail);
> +
> +return AVERROR(EINVAL);
> +}
> +
> return 0;
> }
>
This patch is very problematic: If you change the ref file to match
libaomdec, it will be broken for those that use other decoders than
libaomdec. Actually, there should be no reason to use libaomdec for
probing since 194414f62d987ad831654c45fff6ee27898b832e. Maybe we should
add the AVOID_PROBING cap to the other AV1 decoders in case the native
one is available?
- Andreas
___
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".
Re: [FFmpeg-devel] [PATCH] avcodec/libaomdec: decode extradata in aom_init
On 3/8/2024 6:49 AM, Steven Liu wrote:
before patch:
test failed when using libaomdec.
TESTenhanced-flv-av1
--- src/tests/ref/fate/enhanced-flv-av1 2024-03-08 11:27:13.577935587 +0800
+++ tests/data/fate/enhanced-flv-av12024-03-08 17:38:25.810152322 +0800
@@ -3,7 +3,7 @@
#media_type 0: video
#codec_id 0: av1
#dimensions 0: 320x176
-#sar 0: 0/1
+#sar 0: 1/1
0, 0, 0, 41, 4718, 0xc4d912ec
0, 42, 42, 41, 5109, 0xc065dd7d, F=0x0
0, 83, 83, 41, 192, 0x160c5335, F=0x0
after patch:
test passed
Signed-off-by: Steven Liu
---
libavcodec/libaomdec.c | 12
1 file changed, 12 insertions(+)
diff --git a/libavcodec/libaomdec.c b/libavcodec/libaomdec.c
index 69eec8b089..2df2fa6fd7 100644
--- a/libavcodec/libaomdec.c
+++ b/libavcodec/libaomdec.c
@@ -58,6 +58,18 @@ static av_cold int aom_init(AVCodecContext *avctx,
return AVERROR(EINVAL);
}
+if (aom_codec_decode(>decoder, avctx->extradata, avctx->extradata_size,
+ NULL) != AOM_CODEC_OK) {
Extradata may have the ISOBMFF prefix bytes, so you need to skip them
unless aom_codec_decode() can handle them, which i assume it doesn't.
And of course, if there's nothing after the four prefix bytes, don't
call anything.
+const char *error = aom_codec_error(>decoder);
+const char *detail = aom_codec_error_detail(>decoder);
+
+av_log(avctx, AV_LOG_ERROR, "Failed to decode extradata: %s\n", error);
+if (detail)
+av_log(avctx, AV_LOG_ERROR, " Additional information: %s\n",
detail);
+
+return AVERROR(EINVAL);
+}
+
return 0;
}
___
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".
Re: [FFmpeg-devel] [PATCH] avcodec/xbmenc: Avoid snprintf() for data->hex conversion
Marton Balint:
>
>
> On Fri, 8 Mar 2024, Andreas Rheinhardt wrote:
>
>> Marton Balint:
>>>
>>>
>>> On Fri, 8 Mar 2024, Andreas Rheinhardt wrote:
>>>
Andreas Rheinhardt:
> Use a small LUT instead. Improves performance.
>
> Signed-off-by: Andreas Rheinhardt
> ---
> libavcodec/xbmenc.c | 21 +++--
> 1 file changed, 15 insertions(+), 6 deletions(-)
>
> diff --git a/libavcodec/xbmenc.c b/libavcodec/xbmenc.c
> index cd8b73afa3..5231d4691d 100644
> --- a/libavcodec/xbmenc.c
> +++ b/libavcodec/xbmenc.c
> @@ -20,11 +20,9 @@
> * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
> 02110-1301 USA
> */
>
> -#include "libavutil/reverse.h"
> #include "avcodec.h"
> #include "codec_internal.h"
> #include "encode.h"
> -#include "mathops.h"
>
> #define ANSI_MIN_READLINE 509
>
> @@ -57,14 +55,25 @@ static int xbm_encode_frame(AVCodecContext
> *avctx, AVPacket *pkt,
> buf += snprintf(buf, 39, "static unsigned char image_bits[] =
> {\n");
> for (i = 0, l = lineout; i < avctx->height; i++) {
> for (j = 0; j < linesize; j++) {
> - buf += snprintf(buf, 6, " 0x%02X", ff_reverse[*ptr++]);
> + // 0..15 bitreversed as chars
> + static const char lut[] = {
> + '0', '8', '4', 'C', '2', 'A', '6', 'E',
> + '1', '9', '5', 'D', '3', 'B', '7', 'F'
> + };
> + buf[0] = ' ';
> + buf[1] = '0';
> + buf[2] = 'x';
> + buf[3] = lut[*ptr & 0xF];
> + buf[4] = lut[*ptr >> 4];
>>>
>>> Maybe you could use *buf++ = ... here as well, to avoid the next line.
>>> But fine either way I guess.
>>>
>>
>> You mean *ptr++ to avoid the line after the next line? That would make
>> the two lut accesses unsymmetric. And actually I prefer that both
>> pointers are incremented side-by-side.
>>
>
> I meant this:
>
> diff --git a/libavcodec/xbmenc.c b/libavcodec/xbmenc.c
> index 5231d4691d..20f8951f93 100644
> --- a/libavcodec/xbmenc.c
> +++ b/libavcodec/xbmenc.c
> @@ -60,12 +60,11 @@ static int xbm_encode_frame(AVCodecContext *avctx,
> AVPacket *pkt,
> '0', '8', '4', 'C', '2', 'A', '6', 'E',
> '1', '9', '5', 'D', '3', 'B', '7', 'F'
> };
> - buf[0] = ' ';
> - buf[1] = '0';
> - buf[2] = 'x';
> - buf[3] = lut[*ptr & 0xF];
> - buf[4] = lut[*ptr >> 4];
> - buf += 5;
> + *buf++ = ' ';
> + *buf++ = '0';
> + *buf++ = 'x';
> + *buf++ = lut[*ptr & 0xF];
> + *buf++ = lut[*ptr >> 4];
> ptr++;
> if (--commas <= 0) {
> *buf++ = '\n';
>
>
Ok, I misunderstood. But I still prefer my version.
- Andreas
___
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".
Re: [FFmpeg-devel] [PATCH] avformat/aea: Add aea muxer
asivery via ffmpeg-devel:
> +typedef struct {
> +int block_count;
> +} AeaMuxerContext;
> +
> +static int aea_init(AVFormatContext *s)
> +{
> +AeaMuxerContext *c = s->priv_data;
> +c->block_count = 0;
Unnecessary: A muxer's priv_data is always pre-zeroed.
> +
> +return 0;
> +}
> +
> +static int aea_write_header(AVFormatContext *s)
> +{
> +AVDictionaryEntry *title_entry;
const
> +int title_length = 0, i;
> +char* title_contents;
> +AVStream *st;
> +
> +
> +if (s->nb_streams > 1) {
> +av_log(s, AV_LOG_WARNING, "Got more than one stream to encode, they
> will be ignored.\n");
We don't ignore extraneous streams, we normally error out if something
like this happens.
> +}
> +
> +st = s->streams[0];
> +if (st->codecpar->ch_layout.nb_channels != 1 &&
> st->codecpar->ch_layout.nb_channels != 2) {
> +av_log(s, AV_LOG_ERROR, "Invalid amount of channels to mux (%d).\n",
> st->codecpar->ch_layout.nb_channels);
> +return AVERROR(EINVAL);
> +}
> +
> +if (st->codecpar->sample_rate != 44100) {
> +av_log(s, AV_LOG_ERROR, "Invalid sample rate (%d) AEA only supports
> 44.1kHz.\n", st->codecpar->sample_rate);
> +return AVERROR(EINVAL);
> +}
> +
> +/* Write magic */
> +avio_wl32(s->pb, 2048);
> +
> +/* Write AEA title */
> +title_entry = av_dict_get(st->metadata, "title", NULL, 0);
> +if (title_entry) {
> +title_contents = title_entry->value;
> +title_length = FFMIN(256, strlen(title_contents));
Don't use strlen() in FFMIN (like many macros, it can evaluate its
argument multiple times).
> +}
> +
> +if (title_length) {
> +avio_write(s->pb, title_contents, title_length);
> +}
No need for this branch, just call this inside the "if (title_entry)"
block above.
> +
> +for (i = 0; i<(256 - title_length); i++) {
> +avio_w8(s->pb, 0);
> +}
ffio_fill(). Same below.
> +
> +/* Write number of frames (zero at header-writing time, will seek
> later), number of channels */
> +avio_wl32(s->pb, 0);
> +avio_w8(s->pb, st->codecpar->ch_layout.nb_channels);
> +avio_w8(s->pb, 0);
> +
> +/* Write flags (meaning unknown) */
> +for(i = 0; i<11; i++) {
> +avio_wl32(s->pb, 0);
> +}
> +
> +/* Pad the header to 2048 bytes */
> +for(i = 0; i<1738; i++) avio_w8(s->pb, 0);
> +
> +return 0;
> +}
> +
> +static int aea_write_packet(struct AVFormatContext *s, AVPacket *pkt)
> +{
> +AeaMuxerContext *c = s->priv_data;
> +c->block_count++;
> +
> +avio_write(s->pb, pkt->data, pkt->size);
> +return 0;
You can avoid this and the whole muxer context by using
ff_raw_write_packet() and relying on AVStream.nb_frames.
> +}
> +
> +static int aea_write_trailer(struct AVFormatContext *s)
> +{
> +AVIOContext *pb = s->pb;
> +AeaMuxerContext *c = s->priv_data;
> +if (pb->seekable & AVIO_SEEKABLE_NORMAL) {
> +/* Seek to rewrite the block count. */
> +avio_seek(pb, 260, SEEK_SET);
> +avio_wl32(pb, c->block_count *
> s->streams[0]->codecpar->ch_layout.nb_channels);
> +} else {
> +av_log(s, AV_LOG_WARNING, "unable to rewrite AEA header.\n");
> +}
> +
> +return 0;
> +}
> +
> +const FFOutputFormat ff_aea_muxer = {
> +.p.name = "aea",
> +.p.long_name = NULL_IF_CONFIG_SMALL("MD STUDIO audio"),
> +.priv_data_size = sizeof(AeaMuxerContext),
> +.p.extensions = "aea",
> +.p.audio_codec= AV_CODEC_ID_ATRAC1,
> +.init = aea_init,
> +
> +.write_header = aea_write_header,
> +.write_packet = aea_write_packet,
> +.write_trailer= aea_write_trailer,
> +.p.flags = AVFMT_GENERIC_INDEX,
Makes no sense for a muxer.
> +};
___
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".
[FFmpeg-devel] [PATCH] Fix for Incorrect Parameter in ff_filter_config_links Function Call
From: 联盟少侠
src/libavfilter/internal.h:255:45: note: passing argument to parameter 'filter'
here
int ff_filter_config_links(AVFilterContext *filter);
---
libavfilter/avfilter.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavfilter/avfilter.c b/libavfilter/avfilter.c
index 596a139..c323ebb 100644
--- a/libavfilter/avfilter.c
+++ b/libavfilter/avfilter.c
@@ -214,7 +214,7 @@ void avfilter_link_free(AVFilterLink **link)
}
int avfilter_config_links(AVFilterContext *filter)
{
-return ff_filter_config_links(EINVAL);
+return ff_filter_config_links(filter);
}
#endif
--
2.41.0.windows.3
___
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".
Re: [FFmpeg-devel] [PATCH] avformat/aea: Add aea muxer
Apologies for my oversight.
I've attached the new patch.
- asivery
On Friday, March 8th, 2024 at 12:22 PM, Andreas Rheinhardt
wrote:
> asivery via ffmpeg-devel:
>
> > diff --git a/libavformat/allformats.c b/libavformat/allformats.c
> > index b04b43cab3..1a50181447 100644
> > --- a/libavformat/allformats.c
> > +++ b/libavformat/allformats.c
> > @@ -46,6 +46,7 @@ extern const FFOutputFormat ff_adts_muxer;
> > extern const AVInputFormat ff_adx_demuxer;
> > extern const FFOutputFormat ff_adx_muxer;
> > extern const AVInputFormat ff_aea_demuxer;
> > +extern const FFOutputFormat ff_aea_muxer;
> > extern const AVInputFormat ff_afc_demuxer;
> > extern const AVInputFormat ff_aiff_demuxer;
> > extern const FFOutputFormat ff_aiff_muxer;
> > --
>
>
> Resend the patch rebased on current master.
>
> - Andreas
>
> ___
> 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".From 9323316c9f82a11211ae2e7cb9d8fde5e06772b0 Mon Sep 17 00:00:00 2001
From: asivery
Date: Fri, 8 Mar 2024 12:44:03 +0100
Subject: [PATCH] avformat/aea: Add aea muxer
Signed-off-by: asivery
---
libavformat/Makefile| 3 +-
libavformat/{aea.c => aeadec.c} | 0
libavformat/aeaenc.c| 134
libavformat/allformats.c| 1 +
4 files changed, 137 insertions(+), 1 deletion(-)
rename libavformat/{aea.c => aeadec.c} (100%)
create mode 100644 libavformat/aeaenc.c
diff --git a/libavformat/Makefile b/libavformat/Makefile
index 8811a0ffc9..52e0b1dcad 100644
--- a/libavformat/Makefile
+++ b/libavformat/Makefile
@@ -91,7 +91,8 @@ OBJS-$(CONFIG_ADTS_MUXER)+= adtsenc.o apetag.o img2.o \
id3v2enc.o
OBJS-$(CONFIG_ADX_DEMUXER) += adxdec.o
OBJS-$(CONFIG_ADX_MUXER) += rawenc.o
-OBJS-$(CONFIG_AEA_DEMUXER) += aea.o pcm.o
+OBJS-$(CONFIG_AEA_DEMUXER) += aeadec.o pcm.o
+OBJS-$(CONFIG_AEA_MUXER) += aeaenc.o
OBJS-$(CONFIG_AFC_DEMUXER) += afc.o
OBJS-$(CONFIG_AIFF_DEMUXER) += aiffdec.o aiff.o pcm.o \
mov_chan.o replaygain.o
diff --git a/libavformat/aea.c b/libavformat/aeadec.c
similarity index 100%
rename from libavformat/aea.c
rename to libavformat/aeadec.c
diff --git a/libavformat/aeaenc.c b/libavformat/aeaenc.c
new file mode 100644
index 00..3ce4cec1ee
--- /dev/null
+++ b/libavformat/aeaenc.c
@@ -0,0 +1,134 @@
+/*
+ * MD STUDIO audio muxer
+ *
+ * Copyright (c) 2024 asivery
+ *
+ * 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 Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include "libavutil/channel_layout.h"
+#include "libavutil/intreadwrite.h"
+#include "libavutil/avstring.h"
+#include "avformat.h"
+#include "mux.h"
+
+typedef struct {
+int block_count;
+} AeaMuxerContext;
+
+static int aea_init(AVFormatContext *s)
+{
+AeaMuxerContext *c = s->priv_data;
+c->block_count = 0;
+
+return 0;
+}
+
+static int aea_write_header(AVFormatContext *s)
+{
+AVDictionaryEntry *title_entry;
+int title_length = 0, i;
+char* title_contents;
+AVStream *st;
+
+
+if (s->nb_streams > 1) {
+av_log(s, AV_LOG_WARNING, "Got more than one stream to encode, they will be ignored.\n");
+}
+
+st = s->streams[0];
+if (st->codecpar->ch_layout.nb_channels != 1 && st->codecpar->ch_layout.nb_channels != 2) {
+av_log(s, AV_LOG_ERROR, "Invalid amount of channels to mux (%d).\n", st->codecpar->ch_layout.nb_channels);
+return AVERROR(EINVAL);
+}
+
+if (st->codecpar->sample_rate != 44100) {
+av_log(s, AV_LOG_ERROR, "Invalid sample rate (%d) AEA only supports 44.1kHz.\n", st->codecpar->sample_rate);
+return AVERROR(EINVAL);
+}
+
+/* Write magic */
+avio_wl32(s->pb, 2048);
+
+/* Write AEA title */
+title_entry = av_dict_get(st->metadata, "title", NULL, 0);
+if (title_entry) {
+title_contents = title_entry->value;
+title_length = FFMIN(256, strlen(title_contents));
+}
+
+if (title_length) {
+
Re: [FFmpeg-devel] [PATCH] avformat/aea: Add aea muxer
asivery via ffmpeg-devel: > diff --git a/libavformat/allformats.c b/libavformat/allformats.c > index b04b43cab3..1a50181447 100644 > --- a/libavformat/allformats.c > +++ b/libavformat/allformats.c > @@ -46,6 +46,7 @@ extern const FFOutputFormat ff_adts_muxer; > extern const AVInputFormat ff_adx_demuxer; > extern const FFOutputFormat ff_adx_muxer; > extern const AVInputFormat ff_aea_demuxer; > +extern const FFOutputFormat ff_aea_muxer; > extern const AVInputFormat ff_afc_demuxer; > extern const AVInputFormat ff_aiff_demuxer; > extern const FFOutputFormat ff_aiff_muxer; > -- Resend the patch rebased on current master. - Andreas ___ 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".
[FFmpeg-devel] [PATCH] avformat/aea: Add aea muxer
Empty MessageFrom 955fc035abbb5cfc1a52b1a5ea6900e4a21cef12 Mon Sep 17 00:00:00 2001
From: asivery
Date: Fri, 8 Mar 2024 11:17:51 +0100
Subject: [PATCH] avformat/aea: Add aea muxer
Signed-off-by: asivery
---
libavformat/Makefile| 3 +-
libavformat/{aea.c => aeadec.c} | 0
libavformat/aeaenc.c| 134
libavformat/allformats.c| 1 +
4 files changed, 137 insertions(+), 1 deletion(-)
rename libavformat/{aea.c => aeadec.c} (100%)
create mode 100644 libavformat/aeaenc.c
diff --git a/libavformat/Makefile b/libavformat/Makefile
index 4a380668bd..9855dcc707 100644
--- a/libavformat/Makefile
+++ b/libavformat/Makefile
@@ -91,7 +91,8 @@ OBJS-$(CONFIG_ADTS_MUXER)+= adtsenc.o apetag.o img2.o \
id3v2enc.o
OBJS-$(CONFIG_ADX_DEMUXER) += adxdec.o
OBJS-$(CONFIG_ADX_MUXER) += rawenc.o
-OBJS-$(CONFIG_AEA_DEMUXER) += aea.o pcm.o
+OBJS-$(CONFIG_AEA_DEMUXER) += aeadec.o pcm.o
+OBJS-$(CONFIG_AEA_MUXER) += aeaenc.o
OBJS-$(CONFIG_AFC_DEMUXER) += afc.o
OBJS-$(CONFIG_AIFF_DEMUXER) += aiffdec.o aiff.o pcm.o \
mov_chan.o replaygain.o
diff --git a/libavformat/aea.c b/libavformat/aeadec.c
similarity index 100%
rename from libavformat/aea.c
rename to libavformat/aeadec.c
diff --git a/libavformat/aeaenc.c b/libavformat/aeaenc.c
new file mode 100644
index 00..3ce4cec1ee
--- /dev/null
+++ b/libavformat/aeaenc.c
@@ -0,0 +1,134 @@
+/*
+ * MD STUDIO audio muxer
+ *
+ * Copyright (c) 2024 asivery
+ *
+ * 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 Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include "libavutil/channel_layout.h"
+#include "libavutil/intreadwrite.h"
+#include "libavutil/avstring.h"
+#include "avformat.h"
+#include "mux.h"
+
+typedef struct {
+int block_count;
+} AeaMuxerContext;
+
+static int aea_init(AVFormatContext *s)
+{
+AeaMuxerContext *c = s->priv_data;
+c->block_count = 0;
+
+return 0;
+}
+
+static int aea_write_header(AVFormatContext *s)
+{
+AVDictionaryEntry *title_entry;
+int title_length = 0, i;
+char* title_contents;
+AVStream *st;
+
+
+if (s->nb_streams > 1) {
+av_log(s, AV_LOG_WARNING, "Got more than one stream to encode, they will be ignored.\n");
+}
+
+st = s->streams[0];
+if (st->codecpar->ch_layout.nb_channels != 1 && st->codecpar->ch_layout.nb_channels != 2) {
+av_log(s, AV_LOG_ERROR, "Invalid amount of channels to mux (%d).\n", st->codecpar->ch_layout.nb_channels);
+return AVERROR(EINVAL);
+}
+
+if (st->codecpar->sample_rate != 44100) {
+av_log(s, AV_LOG_ERROR, "Invalid sample rate (%d) AEA only supports 44.1kHz.\n", st->codecpar->sample_rate);
+return AVERROR(EINVAL);
+}
+
+/* Write magic */
+avio_wl32(s->pb, 2048);
+
+/* Write AEA title */
+title_entry = av_dict_get(st->metadata, "title", NULL, 0);
+if (title_entry) {
+title_contents = title_entry->value;
+title_length = FFMIN(256, strlen(title_contents));
+}
+
+if (title_length) {
+avio_write(s->pb, title_contents, title_length);
+}
+
+for (i = 0; i<(256 - title_length); i++) {
+avio_w8(s->pb, 0);
+}
+
+/* Write number of frames (zero at header-writing time, will seek later), number of channels */
+avio_wl32(s->pb, 0);
+avio_w8(s->pb, st->codecpar->ch_layout.nb_channels);
+avio_w8(s->pb, 0);
+
+/* Write flags (meaning unknown) */
+for(i = 0; i<11; i++) {
+avio_wl32(s->pb, 0);
+}
+
+/* Pad the header to 2048 bytes */
+for(i = 0; i<1738; i++) avio_w8(s->pb, 0);
+
+return 0;
+}
+
+static int aea_write_packet(struct AVFormatContext *s, AVPacket *pkt)
+{
+AeaMuxerContext *c = s->priv_data;
+c->block_count++;
+
+avio_write(s->pb, pkt->data, pkt->size);
+return 0;
+}
+
+static int aea_write_trailer(struct AVFormatContext *s)
+{
+AVIOContext *pb = s->pb;
+AeaMuxerContext *c = s->priv_data;
+if (pb->seekable & AVIO_SEEKABLE_NORMAL) {
+/* Seek to rewrite the block count. */
+avio_seek(pb, 260, SEEK_SET);
+avio_wl32(pb,
Re: [FFmpeg-devel] [PATCH 2/3] lavc: replace ff_thread_get_buffer() with ff_get_buffer()
Anton Khirnov: > Quoting Andreas Rheinhardt (2024-03-08 11:44:12) >> Anton Khirnov: >>> Quoting Andreas Rheinhardt (2024-03-08 11:19:59) Anton Khirnov: > Quoting Andreas Rheinhardt (2024-03-08 11:03:18) >> Anton Khirnov: >>> ff_thread_get_buffer() has exactly the same semantics as >>> ff_get_buffer(), except it is supposed to be used in frame-threaded >>> decoders. Since the decoder instance knows whether frame threading is in >>> use, there is no point in forcing decoder implementations to use a >>> different function merely because they happen to support frame >>> threading. >>> --- >>> libavcodec/aic.c | 4 ++-- >>> libavcodec/alac.c | 4 ++-- >>> libavcodec/av1dec.c | 2 +- >>> libavcodec/avcodec_internal.h | 13 + >>> libavcodec/bitpacked_dec.c| 4 ++-- >>> libavcodec/cfhd.c | 4 ++-- >>> libavcodec/cllc.c | 8 >>> libavcodec/cri.c | 2 +- >>> libavcodec/decode.c | 13 - >>> libavcodec/dnxhddec.c | 2 +- >>> libavcodec/dvdec.c| 2 +- >>> libavcodec/dxtory.c | 12 ++-- >>> libavcodec/dxv.c | 4 ++-- >>> libavcodec/exr.c | 2 +- >>> libavcodec/flacdec.c | 4 ++-- >>> libavcodec/fraps.c| 4 ++-- >>> libavcodec/h264_slice.c | 2 +- >>> libavcodec/hapdec.c | 4 ++-- >>> libavcodec/hdrdec.c | 2 +- >>> libavcodec/hevcdec.c | 2 +- >>> libavcodec/hqx.c | 4 ++-- >>> libavcodec/huffyuvdec.c | 4 ++-- >>> libavcodec/jpeg2000dec.c | 2 +- >>> libavcodec/lagarith.c | 12 ++-- >>> libavcodec/lcldec.c | 4 ++-- >>> libavcodec/magicyuv.c | 2 +- >>> libavcodec/mdec.c | 4 ++-- >>> libavcodec/notchlc.c | 2 +- >>> libavcodec/photocd.c | 2 +- >>> libavcodec/pixlet.c | 2 +- >>> libavcodec/pngdec.c | 4 ++-- >>> libavcodec/proresdec2.c | 2 +- >>> libavcodec/pthread_frame.c| 7 ++- >>> libavcodec/qoidec.c | 2 +- >>> libavcodec/rtv1.c | 2 +- >>> libavcodec/sheervideo.c | 4 ++-- >>> libavcodec/takdec.c | 5 +++-- >>> libavcodec/thread.h | 10 -- >>> libavcodec/tiff.c | 2 +- >>> libavcodec/tta.c | 4 ++-- >>> libavcodec/utils.c| 5 - >>> libavcodec/utvideodec.c | 4 ++-- >>> libavcodec/v210dec.c | 4 ++-- >>> libavcodec/v410dec.c | 4 ++-- >>> libavcodec/vaapi_av1.c| 4 ++-- >>> libavcodec/vble.c | 4 ++-- >>> libavcodec/vmixdec.c | 2 +- >>> libavcodec/vvc/vvc_refs.c | 4 ++-- >>> libavcodec/wbmpdec.c | 2 +- >>> libavcodec/webp.c | 2 +- >>> libavcodec/ylc.c | 4 ++-- >>> 51 files changed, 110 insertions(+), 103 deletions(-) >>> >> >> -1: This adds avoidable runtime checks. > > What checks and why is that a problem? > It adds a runtime check to every call to ff_get_buffer() by every decoder not supporting frame-threading (by checking whether frame-threading is currently in use). >>> >>> I cannot imagine any situation where it could have a measurable impact. >>> >> >> And? It is avoidable, therefore it should be avoided. > > Why should it be avoided when it can never have any measurable impact? > > The maintenance cost of a more complex API is higher than the > infinitesimal cost of this check. > What maintenance cost and complexity are you referring to? I checked and could not find a single commit where one had to fix an ff_get_buffer() to ff_thread_get_buffer() because it has been forgotten when the decoder has been declared to support frame threading. - Andreas ___ 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".
Re: [FFmpeg-devel] [PATCH 2/3] lavc: replace ff_thread_get_buffer() with ff_get_buffer()
Quoting Andreas Rheinhardt (2024-03-08 11:44:12) > Anton Khirnov: > > Quoting Andreas Rheinhardt (2024-03-08 11:19:59) > >> Anton Khirnov: > >>> Quoting Andreas Rheinhardt (2024-03-08 11:03:18) > Anton Khirnov: > > ff_thread_get_buffer() has exactly the same semantics as > > ff_get_buffer(), except it is supposed to be used in frame-threaded > > decoders. Since the decoder instance knows whether frame threading is in > > use, there is no point in forcing decoder implementations to use a > > different function merely because they happen to support frame > > threading. > > --- > > libavcodec/aic.c | 4 ++-- > > libavcodec/alac.c | 4 ++-- > > libavcodec/av1dec.c | 2 +- > > libavcodec/avcodec_internal.h | 13 + > > libavcodec/bitpacked_dec.c| 4 ++-- > > libavcodec/cfhd.c | 4 ++-- > > libavcodec/cllc.c | 8 > > libavcodec/cri.c | 2 +- > > libavcodec/decode.c | 13 - > > libavcodec/dnxhddec.c | 2 +- > > libavcodec/dvdec.c| 2 +- > > libavcodec/dxtory.c | 12 ++-- > > libavcodec/dxv.c | 4 ++-- > > libavcodec/exr.c | 2 +- > > libavcodec/flacdec.c | 4 ++-- > > libavcodec/fraps.c| 4 ++-- > > libavcodec/h264_slice.c | 2 +- > > libavcodec/hapdec.c | 4 ++-- > > libavcodec/hdrdec.c | 2 +- > > libavcodec/hevcdec.c | 2 +- > > libavcodec/hqx.c | 4 ++-- > > libavcodec/huffyuvdec.c | 4 ++-- > > libavcodec/jpeg2000dec.c | 2 +- > > libavcodec/lagarith.c | 12 ++-- > > libavcodec/lcldec.c | 4 ++-- > > libavcodec/magicyuv.c | 2 +- > > libavcodec/mdec.c | 4 ++-- > > libavcodec/notchlc.c | 2 +- > > libavcodec/photocd.c | 2 +- > > libavcodec/pixlet.c | 2 +- > > libavcodec/pngdec.c | 4 ++-- > > libavcodec/proresdec2.c | 2 +- > > libavcodec/pthread_frame.c| 7 ++- > > libavcodec/qoidec.c | 2 +- > > libavcodec/rtv1.c | 2 +- > > libavcodec/sheervideo.c | 4 ++-- > > libavcodec/takdec.c | 5 +++-- > > libavcodec/thread.h | 10 -- > > libavcodec/tiff.c | 2 +- > > libavcodec/tta.c | 4 ++-- > > libavcodec/utils.c| 5 - > > libavcodec/utvideodec.c | 4 ++-- > > libavcodec/v210dec.c | 4 ++-- > > libavcodec/v410dec.c | 4 ++-- > > libavcodec/vaapi_av1.c| 4 ++-- > > libavcodec/vble.c | 4 ++-- > > libavcodec/vmixdec.c | 2 +- > > libavcodec/vvc/vvc_refs.c | 4 ++-- > > libavcodec/wbmpdec.c | 2 +- > > libavcodec/webp.c | 2 +- > > libavcodec/ylc.c | 4 ++-- > > 51 files changed, 110 insertions(+), 103 deletions(-) > > > > -1: This adds avoidable runtime checks. > >>> > >>> What checks and why is that a problem? > >>> > >> It adds a runtime check to every call to ff_get_buffer() by every > >> decoder not supporting frame-threading (by checking whether > >> frame-threading is currently in use). > > > > I cannot imagine any situation where it could have a measurable impact. > > > > And? It is avoidable, therefore it should be avoided. Why should it be avoided when it can never have any measurable impact? The maintenance cost of a more complex API is higher than the infinitesimal cost of this check. -- Anton Khirnov ___ 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".
Re: [FFmpeg-devel] [PATCH 2/3] lavc: replace ff_thread_get_buffer() with ff_get_buffer()
Anton Khirnov: > Quoting Andreas Rheinhardt (2024-03-08 11:19:59) >> Anton Khirnov: >>> Quoting Andreas Rheinhardt (2024-03-08 11:03:18) Anton Khirnov: > ff_thread_get_buffer() has exactly the same semantics as > ff_get_buffer(), except it is supposed to be used in frame-threaded > decoders. Since the decoder instance knows whether frame threading is in > use, there is no point in forcing decoder implementations to use a > different function merely because they happen to support frame > threading. > --- > libavcodec/aic.c | 4 ++-- > libavcodec/alac.c | 4 ++-- > libavcodec/av1dec.c | 2 +- > libavcodec/avcodec_internal.h | 13 + > libavcodec/bitpacked_dec.c| 4 ++-- > libavcodec/cfhd.c | 4 ++-- > libavcodec/cllc.c | 8 > libavcodec/cri.c | 2 +- > libavcodec/decode.c | 13 - > libavcodec/dnxhddec.c | 2 +- > libavcodec/dvdec.c| 2 +- > libavcodec/dxtory.c | 12 ++-- > libavcodec/dxv.c | 4 ++-- > libavcodec/exr.c | 2 +- > libavcodec/flacdec.c | 4 ++-- > libavcodec/fraps.c| 4 ++-- > libavcodec/h264_slice.c | 2 +- > libavcodec/hapdec.c | 4 ++-- > libavcodec/hdrdec.c | 2 +- > libavcodec/hevcdec.c | 2 +- > libavcodec/hqx.c | 4 ++-- > libavcodec/huffyuvdec.c | 4 ++-- > libavcodec/jpeg2000dec.c | 2 +- > libavcodec/lagarith.c | 12 ++-- > libavcodec/lcldec.c | 4 ++-- > libavcodec/magicyuv.c | 2 +- > libavcodec/mdec.c | 4 ++-- > libavcodec/notchlc.c | 2 +- > libavcodec/photocd.c | 2 +- > libavcodec/pixlet.c | 2 +- > libavcodec/pngdec.c | 4 ++-- > libavcodec/proresdec2.c | 2 +- > libavcodec/pthread_frame.c| 7 ++- > libavcodec/qoidec.c | 2 +- > libavcodec/rtv1.c | 2 +- > libavcodec/sheervideo.c | 4 ++-- > libavcodec/takdec.c | 5 +++-- > libavcodec/thread.h | 10 -- > libavcodec/tiff.c | 2 +- > libavcodec/tta.c | 4 ++-- > libavcodec/utils.c| 5 - > libavcodec/utvideodec.c | 4 ++-- > libavcodec/v210dec.c | 4 ++-- > libavcodec/v410dec.c | 4 ++-- > libavcodec/vaapi_av1.c| 4 ++-- > libavcodec/vble.c | 4 ++-- > libavcodec/vmixdec.c | 2 +- > libavcodec/vvc/vvc_refs.c | 4 ++-- > libavcodec/wbmpdec.c | 2 +- > libavcodec/webp.c | 2 +- > libavcodec/ylc.c | 4 ++-- > 51 files changed, 110 insertions(+), 103 deletions(-) > -1: This adds avoidable runtime checks. >>> >>> What checks and why is that a problem? >>> >> It adds a runtime check to every call to ff_get_buffer() by every >> decoder not supporting frame-threading (by checking whether >> frame-threading is currently in use). > > I cannot imagine any situation where it could have a measurable impact. > And? It is avoidable, therefore it should be avoided. >> Every avoidable runtime check should always be avoided. > > Premature optimization is the root of all evil. > ___ 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".
Re: [FFmpeg-devel] [PATCH] avfilter/fifo: Remove (a)fifo filters
Muhammad Faiz: > On Tue, Feb 6, 2024 at 3:58 PM Andreas Rheinhardt < > andreas.rheinha...@outlook.com> wrote: > >> Andreas Rheinhardt: >>> Obsolete since 4ca1fb9d2a91757c8c4c34dd456abf340e3f765f. >>> >>> Signed-off-by: Andreas Rheinhardt >>> --- >>> doc/filters.texi | 9 --- >>> libavfilter/Makefile | 1 - >>> libavfilter/allfilters.c | 2 - >>> libavfilter/fifo.c | 165 --- >>> 4 files changed, 177 deletions(-) >>> delete mode 100644 libavfilter/fifo.c >>> >> >> Will apply in a few days unless there are objections. >> >> - Andreas >> >> > This breaks backward compatibility. > > Please revert. > > Thank's. What breaks that can't simply be fixed by removing the (a)fifo filter from the filterchain? - Andreas ___ 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".
Re: [FFmpeg-devel] [PATCH 2/3] lavc: replace ff_thread_get_buffer() with ff_get_buffer()
Quoting Andreas Rheinhardt (2024-03-08 11:19:59) > Anton Khirnov: > > Quoting Andreas Rheinhardt (2024-03-08 11:03:18) > >> Anton Khirnov: > >>> ff_thread_get_buffer() has exactly the same semantics as > >>> ff_get_buffer(), except it is supposed to be used in frame-threaded > >>> decoders. Since the decoder instance knows whether frame threading is in > >>> use, there is no point in forcing decoder implementations to use a > >>> different function merely because they happen to support frame > >>> threading. > >>> --- > >>> libavcodec/aic.c | 4 ++-- > >>> libavcodec/alac.c | 4 ++-- > >>> libavcodec/av1dec.c | 2 +- > >>> libavcodec/avcodec_internal.h | 13 + > >>> libavcodec/bitpacked_dec.c| 4 ++-- > >>> libavcodec/cfhd.c | 4 ++-- > >>> libavcodec/cllc.c | 8 > >>> libavcodec/cri.c | 2 +- > >>> libavcodec/decode.c | 13 - > >>> libavcodec/dnxhddec.c | 2 +- > >>> libavcodec/dvdec.c| 2 +- > >>> libavcodec/dxtory.c | 12 ++-- > >>> libavcodec/dxv.c | 4 ++-- > >>> libavcodec/exr.c | 2 +- > >>> libavcodec/flacdec.c | 4 ++-- > >>> libavcodec/fraps.c| 4 ++-- > >>> libavcodec/h264_slice.c | 2 +- > >>> libavcodec/hapdec.c | 4 ++-- > >>> libavcodec/hdrdec.c | 2 +- > >>> libavcodec/hevcdec.c | 2 +- > >>> libavcodec/hqx.c | 4 ++-- > >>> libavcodec/huffyuvdec.c | 4 ++-- > >>> libavcodec/jpeg2000dec.c | 2 +- > >>> libavcodec/lagarith.c | 12 ++-- > >>> libavcodec/lcldec.c | 4 ++-- > >>> libavcodec/magicyuv.c | 2 +- > >>> libavcodec/mdec.c | 4 ++-- > >>> libavcodec/notchlc.c | 2 +- > >>> libavcodec/photocd.c | 2 +- > >>> libavcodec/pixlet.c | 2 +- > >>> libavcodec/pngdec.c | 4 ++-- > >>> libavcodec/proresdec2.c | 2 +- > >>> libavcodec/pthread_frame.c| 7 ++- > >>> libavcodec/qoidec.c | 2 +- > >>> libavcodec/rtv1.c | 2 +- > >>> libavcodec/sheervideo.c | 4 ++-- > >>> libavcodec/takdec.c | 5 +++-- > >>> libavcodec/thread.h | 10 -- > >>> libavcodec/tiff.c | 2 +- > >>> libavcodec/tta.c | 4 ++-- > >>> libavcodec/utils.c| 5 - > >>> libavcodec/utvideodec.c | 4 ++-- > >>> libavcodec/v210dec.c | 4 ++-- > >>> libavcodec/v410dec.c | 4 ++-- > >>> libavcodec/vaapi_av1.c| 4 ++-- > >>> libavcodec/vble.c | 4 ++-- > >>> libavcodec/vmixdec.c | 2 +- > >>> libavcodec/vvc/vvc_refs.c | 4 ++-- > >>> libavcodec/wbmpdec.c | 2 +- > >>> libavcodec/webp.c | 2 +- > >>> libavcodec/ylc.c | 4 ++-- > >>> 51 files changed, 110 insertions(+), 103 deletions(-) > >>> > >> > >> -1: This adds avoidable runtime checks. > > > > What checks and why is that a problem? > > > It adds a runtime check to every call to ff_get_buffer() by every > decoder not supporting frame-threading (by checking whether > frame-threading is currently in use). I cannot imagine any situation where it could have a measurable impact. > Every avoidable runtime check should always be avoided. Premature optimization is the root of all evil. -- Anton Khirnov ___ 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".
Re: [FFmpeg-devel] [PATCH 2/3] lavc: replace ff_thread_get_buffer() with ff_get_buffer()
Anton Khirnov: > Quoting Andreas Rheinhardt (2024-03-08 11:03:18) >> Anton Khirnov: >>> ff_thread_get_buffer() has exactly the same semantics as >>> ff_get_buffer(), except it is supposed to be used in frame-threaded >>> decoders. Since the decoder instance knows whether frame threading is in >>> use, there is no point in forcing decoder implementations to use a >>> different function merely because they happen to support frame >>> threading. >>> --- >>> libavcodec/aic.c | 4 ++-- >>> libavcodec/alac.c | 4 ++-- >>> libavcodec/av1dec.c | 2 +- >>> libavcodec/avcodec_internal.h | 13 + >>> libavcodec/bitpacked_dec.c| 4 ++-- >>> libavcodec/cfhd.c | 4 ++-- >>> libavcodec/cllc.c | 8 >>> libavcodec/cri.c | 2 +- >>> libavcodec/decode.c | 13 - >>> libavcodec/dnxhddec.c | 2 +- >>> libavcodec/dvdec.c| 2 +- >>> libavcodec/dxtory.c | 12 ++-- >>> libavcodec/dxv.c | 4 ++-- >>> libavcodec/exr.c | 2 +- >>> libavcodec/flacdec.c | 4 ++-- >>> libavcodec/fraps.c| 4 ++-- >>> libavcodec/h264_slice.c | 2 +- >>> libavcodec/hapdec.c | 4 ++-- >>> libavcodec/hdrdec.c | 2 +- >>> libavcodec/hevcdec.c | 2 +- >>> libavcodec/hqx.c | 4 ++-- >>> libavcodec/huffyuvdec.c | 4 ++-- >>> libavcodec/jpeg2000dec.c | 2 +- >>> libavcodec/lagarith.c | 12 ++-- >>> libavcodec/lcldec.c | 4 ++-- >>> libavcodec/magicyuv.c | 2 +- >>> libavcodec/mdec.c | 4 ++-- >>> libavcodec/notchlc.c | 2 +- >>> libavcodec/photocd.c | 2 +- >>> libavcodec/pixlet.c | 2 +- >>> libavcodec/pngdec.c | 4 ++-- >>> libavcodec/proresdec2.c | 2 +- >>> libavcodec/pthread_frame.c| 7 ++- >>> libavcodec/qoidec.c | 2 +- >>> libavcodec/rtv1.c | 2 +- >>> libavcodec/sheervideo.c | 4 ++-- >>> libavcodec/takdec.c | 5 +++-- >>> libavcodec/thread.h | 10 -- >>> libavcodec/tiff.c | 2 +- >>> libavcodec/tta.c | 4 ++-- >>> libavcodec/utils.c| 5 - >>> libavcodec/utvideodec.c | 4 ++-- >>> libavcodec/v210dec.c | 4 ++-- >>> libavcodec/v410dec.c | 4 ++-- >>> libavcodec/vaapi_av1.c| 4 ++-- >>> libavcodec/vble.c | 4 ++-- >>> libavcodec/vmixdec.c | 2 +- >>> libavcodec/vvc/vvc_refs.c | 4 ++-- >>> libavcodec/wbmpdec.c | 2 +- >>> libavcodec/webp.c | 2 +- >>> libavcodec/ylc.c | 4 ++-- >>> 51 files changed, 110 insertions(+), 103 deletions(-) >>> >> >> -1: This adds avoidable runtime checks. > > What checks and why is that a problem? > It adds a runtime check to every call to ff_get_buffer() by every decoder not supporting frame-threading (by checking whether frame-threading is currently in use). Every avoidable runtime check should always be avoided. - Andreas ___ 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".
Re: [FFmpeg-devel] [PATCH 2/3] lavc: replace ff_thread_get_buffer() with ff_get_buffer()
Quoting Andreas Rheinhardt (2024-03-08 11:03:18) > Anton Khirnov: > > ff_thread_get_buffer() has exactly the same semantics as > > ff_get_buffer(), except it is supposed to be used in frame-threaded > > decoders. Since the decoder instance knows whether frame threading is in > > use, there is no point in forcing decoder implementations to use a > > different function merely because they happen to support frame > > threading. > > --- > > libavcodec/aic.c | 4 ++-- > > libavcodec/alac.c | 4 ++-- > > libavcodec/av1dec.c | 2 +- > > libavcodec/avcodec_internal.h | 13 + > > libavcodec/bitpacked_dec.c| 4 ++-- > > libavcodec/cfhd.c | 4 ++-- > > libavcodec/cllc.c | 8 > > libavcodec/cri.c | 2 +- > > libavcodec/decode.c | 13 - > > libavcodec/dnxhddec.c | 2 +- > > libavcodec/dvdec.c| 2 +- > > libavcodec/dxtory.c | 12 ++-- > > libavcodec/dxv.c | 4 ++-- > > libavcodec/exr.c | 2 +- > > libavcodec/flacdec.c | 4 ++-- > > libavcodec/fraps.c| 4 ++-- > > libavcodec/h264_slice.c | 2 +- > > libavcodec/hapdec.c | 4 ++-- > > libavcodec/hdrdec.c | 2 +- > > libavcodec/hevcdec.c | 2 +- > > libavcodec/hqx.c | 4 ++-- > > libavcodec/huffyuvdec.c | 4 ++-- > > libavcodec/jpeg2000dec.c | 2 +- > > libavcodec/lagarith.c | 12 ++-- > > libavcodec/lcldec.c | 4 ++-- > > libavcodec/magicyuv.c | 2 +- > > libavcodec/mdec.c | 4 ++-- > > libavcodec/notchlc.c | 2 +- > > libavcodec/photocd.c | 2 +- > > libavcodec/pixlet.c | 2 +- > > libavcodec/pngdec.c | 4 ++-- > > libavcodec/proresdec2.c | 2 +- > > libavcodec/pthread_frame.c| 7 ++- > > libavcodec/qoidec.c | 2 +- > > libavcodec/rtv1.c | 2 +- > > libavcodec/sheervideo.c | 4 ++-- > > libavcodec/takdec.c | 5 +++-- > > libavcodec/thread.h | 10 -- > > libavcodec/tiff.c | 2 +- > > libavcodec/tta.c | 4 ++-- > > libavcodec/utils.c| 5 - > > libavcodec/utvideodec.c | 4 ++-- > > libavcodec/v210dec.c | 4 ++-- > > libavcodec/v410dec.c | 4 ++-- > > libavcodec/vaapi_av1.c| 4 ++-- > > libavcodec/vble.c | 4 ++-- > > libavcodec/vmixdec.c | 2 +- > > libavcodec/vvc/vvc_refs.c | 4 ++-- > > libavcodec/wbmpdec.c | 2 +- > > libavcodec/webp.c | 2 +- > > libavcodec/ylc.c | 4 ++-- > > 51 files changed, 110 insertions(+), 103 deletions(-) > > > > -1: This adds avoidable runtime checks. What checks and why is that a problem? -- Anton Khirnov ___ 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".
Re: [FFmpeg-devel] [PATCH] libavdevice: Fix the avfoundation device after switching to FFInputFormat
Martin Storsjö:
> This was missed in b800327f4c7233d09baca958121722a04c2035ff.
> ---
> libavdevice/avfoundation.m | 11 ++-
> 1 file changed, 6 insertions(+), 5 deletions(-)
>
> diff --git a/libavdevice/avfoundation.m b/libavdevice/avfoundation.m
> index a0ef87edff..d9b17ccdae 100644
> --- a/libavdevice/avfoundation.m
> +++ b/libavdevice/avfoundation.m
> @@ -32,6 +32,7 @@
> #include "libavutil/pixdesc.h"
> #include "libavutil/opt.h"
> #include "libavutil/avstring.h"
> +#include "libavformat/demux.h"
> #include "libavformat/internal.h"
> #include "libavutil/internal.h"
> #include "libavutil/parseutils.h"
> @@ -1292,13 +1293,13 @@ static int avf_close(AVFormatContext *s)
> .category = AV_CLASS_CATEGORY_DEVICE_VIDEO_INPUT,
> };
>
> -const AVInputFormat ff_avfoundation_demuxer = {
> -.name = "avfoundation",
> -.long_name = NULL_IF_CONFIG_SMALL("AVFoundation input device"),
> +const FFInputFormat ff_avfoundation_demuxer = {
> +.p.name = "avfoundation",
> +.p.long_name= NULL_IF_CONFIG_SMALL("AVFoundation input device"),
> +.p.flags= AVFMT_NOFILE,
> +.p.priv_class = _class,
> .priv_data_size = sizeof(AVFContext),
> .read_header= avf_read_header,
> .read_packet= avf_read_packet,
> .read_close = avf_close,
> -.flags = AVFMT_NOFILE,
> -.priv_class = _class,
> };
LGTM. Sorry for having missed this.
- Andreas
___
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".
Re: [FFmpeg-devel] [PATCH 2/3] lavc: replace ff_thread_get_buffer() with ff_get_buffer()
Anton Khirnov: > ff_thread_get_buffer() has exactly the same semantics as > ff_get_buffer(), except it is supposed to be used in frame-threaded > decoders. Since the decoder instance knows whether frame threading is in > use, there is no point in forcing decoder implementations to use a > different function merely because they happen to support frame > threading. > --- > libavcodec/aic.c | 4 ++-- > libavcodec/alac.c | 4 ++-- > libavcodec/av1dec.c | 2 +- > libavcodec/avcodec_internal.h | 13 + > libavcodec/bitpacked_dec.c| 4 ++-- > libavcodec/cfhd.c | 4 ++-- > libavcodec/cllc.c | 8 > libavcodec/cri.c | 2 +- > libavcodec/decode.c | 13 - > libavcodec/dnxhddec.c | 2 +- > libavcodec/dvdec.c| 2 +- > libavcodec/dxtory.c | 12 ++-- > libavcodec/dxv.c | 4 ++-- > libavcodec/exr.c | 2 +- > libavcodec/flacdec.c | 4 ++-- > libavcodec/fraps.c| 4 ++-- > libavcodec/h264_slice.c | 2 +- > libavcodec/hapdec.c | 4 ++-- > libavcodec/hdrdec.c | 2 +- > libavcodec/hevcdec.c | 2 +- > libavcodec/hqx.c | 4 ++-- > libavcodec/huffyuvdec.c | 4 ++-- > libavcodec/jpeg2000dec.c | 2 +- > libavcodec/lagarith.c | 12 ++-- > libavcodec/lcldec.c | 4 ++-- > libavcodec/magicyuv.c | 2 +- > libavcodec/mdec.c | 4 ++-- > libavcodec/notchlc.c | 2 +- > libavcodec/photocd.c | 2 +- > libavcodec/pixlet.c | 2 +- > libavcodec/pngdec.c | 4 ++-- > libavcodec/proresdec2.c | 2 +- > libavcodec/pthread_frame.c| 7 ++- > libavcodec/qoidec.c | 2 +- > libavcodec/rtv1.c | 2 +- > libavcodec/sheervideo.c | 4 ++-- > libavcodec/takdec.c | 5 +++-- > libavcodec/thread.h | 10 -- > libavcodec/tiff.c | 2 +- > libavcodec/tta.c | 4 ++-- > libavcodec/utils.c| 5 - > libavcodec/utvideodec.c | 4 ++-- > libavcodec/v210dec.c | 4 ++-- > libavcodec/v410dec.c | 4 ++-- > libavcodec/vaapi_av1.c| 4 ++-- > libavcodec/vble.c | 4 ++-- > libavcodec/vmixdec.c | 2 +- > libavcodec/vvc/vvc_refs.c | 4 ++-- > libavcodec/wbmpdec.c | 2 +- > libavcodec/webp.c | 2 +- > libavcodec/ylc.c | 4 ++-- > 51 files changed, 110 insertions(+), 103 deletions(-) > -1: This adds avoidable runtime checks. - Andreas ___ 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".
[FFmpeg-devel] [PATCH] avcodec/libaomdec: decode extradata in aom_init
before patch:
test failed when using libaomdec.
TESTenhanced-flv-av1
--- src/tests/ref/fate/enhanced-flv-av1 2024-03-08 11:27:13.577935587 +0800
+++ tests/data/fate/enhanced-flv-av12024-03-08 17:38:25.810152322 +0800
@@ -3,7 +3,7 @@
#media_type 0: video
#codec_id 0: av1
#dimensions 0: 320x176
-#sar 0: 0/1
+#sar 0: 1/1
0, 0, 0, 41, 4718, 0xc4d912ec
0, 42, 42, 41, 5109, 0xc065dd7d, F=0x0
0, 83, 83, 41, 192, 0x160c5335, F=0x0
after patch:
test passed
Signed-off-by: Steven Liu
---
libavcodec/libaomdec.c | 12
1 file changed, 12 insertions(+)
diff --git a/libavcodec/libaomdec.c b/libavcodec/libaomdec.c
index 69eec8b089..2df2fa6fd7 100644
--- a/libavcodec/libaomdec.c
+++ b/libavcodec/libaomdec.c
@@ -58,6 +58,18 @@ static av_cold int aom_init(AVCodecContext *avctx,
return AVERROR(EINVAL);
}
+if (aom_codec_decode(>decoder, avctx->extradata,
avctx->extradata_size,
+ NULL) != AOM_CODEC_OK) {
+const char *error = aom_codec_error(>decoder);
+const char *detail = aom_codec_error_detail(>decoder);
+
+av_log(avctx, AV_LOG_ERROR, "Failed to decode extradata: %s\n", error);
+if (detail)
+av_log(avctx, AV_LOG_ERROR, " Additional information: %s\n",
detail);
+
+return AVERROR(EINVAL);
+}
+
return 0;
}
--
2.39.3 (Apple Git-146)
___
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".
Re: [FFmpeg-devel] [PATCH 2/2] lavc/vc1dsp: R-V V mspel_pixels
Alright, using m8, but for now don't add code to address dependencies in
loops that have a minor impact. Updated in the reply
Rémi Denis-Courmont 于2024年3月8日周五 17:08写道：
>
>
> Le 8 mars 2024 02:45:46 GMT+02:00, flow gg a
> écrit :
> >> Isn't it also faster to max LMUL for the adds here?
> >
> >It requires the use of one more vset, making the time slightly longer:
> >147.7 (m1), 148.7 (m8 + vset).
>
> A variation of 0.6% on a single set of kernels will end up below
> measurement noise in real overall codec usage. And then reducing the
> I-cache contention can improve performance in other ways. Larger LMUL
> should also improve performance on bigger cores with more ALUs. So it's not
> all black and white.
>
> My personal preference is to keep the code small if it makes almost no
> difference but I'm not BDFL.
>
> >Also this might not be much noticeable on C908, but avoiding sequential
> >dependencies on the address registers may help. I mean, avoid using as
> >address
> >operand a value that was calculated by the immediate previous instruction.
> >
> >> Okay, but the test results haven't changed..
> >It would add more than ten lines of code, perhaps shorter code will
> better?
>
> I don't know. There are definitely in-order vector cores coming, and data
> dependencies will hurt them. But I don't know if anyone will care about
> FFmpeg on those.
> ___
> 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".
>
From 47ae233e6bb8f52dd7d92ac062bed1ac85ac49a0 Mon Sep 17 00:00:00 2001
From: sunyuechi
Date: Wed, 28 Feb 2024 16:32:39 +0800
Subject: [PATCH 2/2] lavc/vc1dsp: R-V V mspel_pixels
vc1dsp.avg_vc1_mspel_pixels_tab[0][0]_c: 869.7
vc1dsp.avg_vc1_mspel_pixels_tab[0][0]_rvv_i32: 148.7
vc1dsp.avg_vc1_mspel_pixels_tab[1][0]_c: 220.5
vc1dsp.avg_vc1_mspel_pixels_tab[1][0]_rvv_i64: 56.2
vc1dsp.put_vc1_mspel_pixels_tab[0][0]_c: 523.7
vc1dsp.put_vc1_mspel_pixels_tab[0][0]_rvv_i32: 82.0
vc1dsp.put_vc1_mspel_pixels_tab[1][0]_c: 138.5
vc1dsp.put_vc1_mspel_pixels_tab[1][0]_rvv_i64: 23.7
vc1tmp
---
libavcodec/riscv/vc1dsp_init.c | 8 +
libavcodec/riscv/vc1dsp_rvv.S | 66 ++
2 files changed, 74 insertions(+)
diff --git a/libavcodec/riscv/vc1dsp_init.c b/libavcodec/riscv/vc1dsp_init.c
index e47b644f80..610c43a1a3 100644
--- a/libavcodec/riscv/vc1dsp_init.c
+++ b/libavcodec/riscv/vc1dsp_init.c
@@ -29,6 +29,10 @@ void ff_vc1_inv_trans_8x8_dc_rvv(uint8_t *dest, ptrdiff_t stride, int16_t *block
void ff_vc1_inv_trans_4x8_dc_rvv(uint8_t *dest, ptrdiff_t stride, int16_t *block);
void ff_vc1_inv_trans_8x4_dc_rvv(uint8_t *dest, ptrdiff_t stride, int16_t *block);
void ff_vc1_inv_trans_4x4_dc_rvv(uint8_t *dest, ptrdiff_t stride, int16_t *block);
+void ff_put_pixels16x16_rvv(uint8_t *dst, const uint8_t *src, ptrdiff_t line_size, int rnd);
+void ff_put_pixels8x8_rvv(uint8_t *dst, const uint8_t *src, ptrdiff_t line_size, int rnd);
+void ff_avg_pixels16x16_rvv(uint8_t *dst, const uint8_t *src, ptrdiff_t line_size, int rnd);
+void ff_avg_pixels8x8_rvv(uint8_t *dst, const uint8_t *src, ptrdiff_t line_size, int rnd);
av_cold void ff_vc1dsp_init_riscv(VC1DSPContext *dsp)
{
@@ -38,9 +42,13 @@ av_cold void ff_vc1dsp_init_riscv(VC1DSPContext *dsp)
if (flags & AV_CPU_FLAG_RVV_I32 && ff_get_rv_vlenb() >= 16) {
dsp->vc1_inv_trans_4x8_dc = ff_vc1_inv_trans_4x8_dc_rvv;
dsp->vc1_inv_trans_4x4_dc = ff_vc1_inv_trans_4x4_dc_rvv;
+dsp->put_vc1_mspel_pixels_tab[0][0] = ff_put_pixels16x16_rvv;
+dsp->avg_vc1_mspel_pixels_tab[0][0] = ff_avg_pixels16x16_rvv;
if (flags & AV_CPU_FLAG_RVV_I64) {
dsp->vc1_inv_trans_8x8_dc = ff_vc1_inv_trans_8x8_dc_rvv;
dsp->vc1_inv_trans_8x4_dc = ff_vc1_inv_trans_8x4_dc_rvv;
+dsp->put_vc1_mspel_pixels_tab[1][0] = ff_put_pixels8x8_rvv;
+dsp->avg_vc1_mspel_pixels_tab[1][0] = ff_avg_pixels8x8_rvv;
}
}
#endif
diff --git a/libavcodec/riscv/vc1dsp_rvv.S b/libavcodec/riscv/vc1dsp_rvv.S
index 4a00945ead..48244f91aa 100644
--- a/libavcodec/riscv/vc1dsp_rvv.S
+++ b/libavcodec/riscv/vc1dsp_rvv.S
@@ -111,3 +111,69 @@ func ff_vc1_inv_trans_4x4_dc_rvv, zve32x
vsse32.v v0, (a0), a1
ret
endfunc
+
+func ff_put_pixels16x16_rvv, zve32x
+vsetivli zero, 16, e8, m1, ta, ma
+.irp n 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30
+vle8.vv\n, (a1)
+add a1, a1, a2
+.endr
+vle8.vv31, (a1)
+.irp n 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30
+vse8.vv\n, (a0)
+add a0, a0, a2
+.endr
+vse8.vv31, (a0)
+
+ret
+endfunc
+
+func ff_put_pixels8x8_rvv, zve64x
+vsetivli zero, 8, e8, mf2, ta, ma
+
Re: [FFmpeg-devel] [PATCH 2/2] lavc/vc1dsp: R-V V mspel_pixels
Le 8 mars 2024 02:45:46 GMT+02:00, flow gg a écrit : >> Isn't it also faster to max LMUL for the adds here? > >It requires the use of one more vset, making the time slightly longer: >147.7 (m1), 148.7 (m8 + vset). A variation of 0.6% on a single set of kernels will end up below measurement noise in real overall codec usage. And then reducing the I-cache contention can improve performance in other ways. Larger LMUL should also improve performance on bigger cores with more ALUs. So it's not all black and white. My personal preference is to keep the code small if it makes almost no difference but I'm not BDFL. >Also this might not be much noticeable on C908, but avoiding sequential >dependencies on the address registers may help. I mean, avoid using as >address >operand a value that was calculated by the immediate previous instruction. > >> Okay, but the test results haven't changed.. >It would add more than ten lines of code, perhaps shorter code will better? I don't know. There are definitely in-order vector cores coming, and data dependencies will hurt them. But I don't know if anyone will care about FFmpeg on those. ___ 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".
[FFmpeg-devel] [PATCH v2 2/2] lavc/vaapi_encode_h265: Set general_*_constriaint flags with profile
From: Fei Wang
According to Table A.2 in spec.
Signed-off-by: Fei Wang
---
libavcodec/vaapi_encode_h265.c | 181 +++--
1 file changed, 128 insertions(+), 53 deletions(-)
diff --git a/libavcodec/vaapi_encode_h265.c b/libavcodec/vaapi_encode_h265.c
index 43755e2188..7c9916eac8 100644
--- a/libavcodec/vaapi_encode_h265.c
+++ b/libavcodec/vaapi_encode_h265.c
@@ -258,6 +258,129 @@ fail:
return err;
}
+static int vaapi_encode_h265_init_ptl(AVCodecContext *avctx)
+{
+VAAPIEncodeContext *ctx = avctx->priv_data;
+VAAPIEncodeH265Context *priv = avctx->priv_data;
+H265RawVPS *vps = >raw_vps;
+H265RawProfileTierLevel *ptl = >profile_tier_level;
+
+ptl->general_profile_space = 0;
+ptl->general_profile_idc = avctx->profile;
+ptl->general_tier_flag = priv->tier;
+
+ptl->general_profile_compatibility_flag[ptl->general_profile_idc] = 1;
+
+if (ptl->general_profile_compatibility_flag[1])
+ptl->general_profile_compatibility_flag[2] = 1;
+if (ptl->general_profile_compatibility_flag[3]) {
+ptl->general_profile_compatibility_flag[1] = 1;
+ptl->general_profile_compatibility_flag[2] = 1;
+}
+
+ptl->general_progressive_source_flag= 1;
+ptl->general_interlaced_source_flag = 0;
+ptl->general_non_packed_constraint_flag = 1;
+ptl->general_frame_only_constraint_flag = 1;
+
+if (avctx->profile >= 4) {
+ptl->general_intra_constraint_flag= ctx->gop_size == 1;
+ptl->general_one_picture_only_constraint_flag = 0;
+ptl->general_lower_bit_rate_constraint_flag = 1;
+
+switch (ctx->va_profile) {
+#if VA_CHECK_VERSION(1, 2, 0)
+case VAProfileHEVCMain12:
+// Main 12
+ptl->general_max_14bit_constraint_flag = 0;
+ptl->general_max_12bit_constraint_flag = 1;
+ptl->general_max_10bit_constraint_flag = 0;
+ptl->general_max_8bit_constraint_flag = 0;
+ptl->general_max_422chroma_constraint_flag = 1;
+ptl->general_max_420chroma_constraint_flag = 1;
+ptl->general_max_monochrome_constraint_flag = 0;
+break;
+case VAProfileHEVCMain422_10:
+// Main 4:2:2 10
+ptl->general_max_14bit_constraint_flag = 0;
+ptl->general_max_12bit_constraint_flag = 1;
+ptl->general_max_10bit_constraint_flag = 1;
+ptl->general_max_8bit_constraint_flag = 0;
+ptl->general_max_422chroma_constraint_flag = 1;
+ptl->general_max_420chroma_constraint_flag = 0;
+ptl->general_max_monochrome_constraint_flag = 0;
+break;
+case VAProfileHEVCMain422_12:
+// Main 4:2:2 12
+ptl->general_max_14bit_constraint_flag = 0;
+ptl->general_max_12bit_constraint_flag = 1;
+ptl->general_max_10bit_constraint_flag = 0;
+ptl->general_max_8bit_constraint_flag = 0;
+ptl->general_max_422chroma_constraint_flag = 1;
+ptl->general_max_420chroma_constraint_flag = 0;
+ptl->general_max_monochrome_constraint_flag = 0;
+break;
+case VAProfileHEVCMain444:
+// Main 4:4:4
+ptl->general_max_14bit_constraint_flag = 0;
+ptl->general_max_12bit_constraint_flag = 1;
+ptl->general_max_10bit_constraint_flag = 1;
+ptl->general_max_8bit_constraint_flag = 1;
+ptl->general_max_422chroma_constraint_flag = 0;
+ptl->general_max_420chroma_constraint_flag = 0;
+ptl->general_max_monochrome_constraint_flag = 0;
+break;
+case VAProfileHEVCMain444_10:
+// Main 4:4:4 10
+ptl->general_max_14bit_constraint_flag = 0;
+ptl->general_max_12bit_constraint_flag = 1;
+ptl->general_max_10bit_constraint_flag = 1;
+ptl->general_max_8bit_constraint_flag = 0;
+ptl->general_max_422chroma_constraint_flag = 0;
+ptl->general_max_420chroma_constraint_flag = 0;
+ptl->general_max_monochrome_constraint_flag = 0;
+break;
+case VAProfileHEVCMain444_12:
+// Main 4:4:4 12
+ptl->general_max_14bit_constraint_flag = 0;
+ptl->general_max_12bit_constraint_flag = 1;
+ptl->general_max_10bit_constraint_flag = 0;
+ptl->general_max_8bit_constraint_flag = 0;
+ptl->general_max_422chroma_constraint_flag = 0;
+ptl->general_max_420chroma_constraint_flag = 0;
+ptl->general_max_monochrome_constraint_flag = 0;
+break;
+#endif
+default:
+av_log(avctx, AV_LOG_ERROR, "Unknown profile to init PTL.\n");
+return AVERROR(EINVAL);
+}
+}
[FFmpeg-devel] [PATCH v2 1/2] lavc/vaapi_encode_h265: Map HEVC AV REXT profile to VA REXT profile
From: Fei Wang
There is no Main8/10 profile defined in HEVC REXT profiles. Use Main12
which is compatible with 8/10bit.
Signed-off-by: Fei Wang
---
update:
Add more explanation in commit log.
libavcodec/vaapi_encode_h265.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavcodec/vaapi_encode_h265.c b/libavcodec/vaapi_encode_h265.c
index c4aabbf5ed..43755e2188 100644
--- a/libavcodec/vaapi_encode_h265.c
+++ b/libavcodec/vaapi_encode_h265.c
@@ -1305,12 +1305,12 @@ static av_cold int
vaapi_encode_h265_configure(AVCodecContext *avctx)
static const VAAPIEncodeProfile vaapi_encode_h265_profiles[] = {
{ AV_PROFILE_HEVC_MAIN, 8, 3, 1, 1, VAProfileHEVCMain },
-{ AV_PROFILE_HEVC_REXT, 8, 3, 1, 1, VAProfileHEVCMain },
#if VA_CHECK_VERSION(0, 37, 0)
{ AV_PROFILE_HEVC_MAIN_10, 10, 3, 1, 1, VAProfileHEVCMain10 },
-{ AV_PROFILE_HEVC_REXT,10, 3, 1, 1, VAProfileHEVCMain10 },
#endif
#if VA_CHECK_VERSION(1, 2, 0)
+{ AV_PROFILE_HEVC_REXT, 8, 3, 1, 1, VAProfileHEVCMain12 },
+{ AV_PROFILE_HEVC_REXT,10, 3, 1, 1, VAProfileHEVCMain12 },
{ AV_PROFILE_HEVC_REXT,12, 3, 1, 1, VAProfileHEVCMain12 },
{ AV_PROFILE_HEVC_REXT, 8, 3, 1, 0, VAProfileHEVCMain422_10 },
{ AV_PROFILE_HEVC_REXT,10, 3, 1, 0, VAProfileHEVCMain422_10 },
--
2.25.1
___
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".
Re: [FFmpeg-devel] [PATCH] avfilter/fifo: Remove (a)fifo filters
On Tue, Feb 6, 2024 at 3:58 PM Andreas Rheinhardt < andreas.rheinha...@outlook.com> wrote: > Andreas Rheinhardt: > > Obsolete since 4ca1fb9d2a91757c8c4c34dd456abf340e3f765f. > > > > Signed-off-by: Andreas Rheinhardt > > --- > > doc/filters.texi | 9 --- > > libavfilter/Makefile | 1 - > > libavfilter/allfilters.c | 2 - > > libavfilter/fifo.c | 165 --- > > 4 files changed, 177 deletions(-) > > delete mode 100644 libavfilter/fifo.c > > > > Will apply in a few days unless there are objections. > > - Andreas > > This breaks backward compatibility. Please revert. Thank's. ___ 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".
[FFmpeg-devel] [PATCH v3] lavc/vaapi_encode: Enable block level bitrate control
From: Fei Wang
Signed-off-by: Fei Wang
---
doc/encoders.texi | 4
libavcodec/vaapi_encode.c | 13 -
libavcodec/vaapi_encode.h | 9 -
3 files changed, 24 insertions(+), 2 deletions(-)
diff --git a/doc/encoders.texi b/doc/encoders.texi
index 5f7864770e..7c223ed74c 100644
--- a/doc/encoders.texi
+++ b/doc/encoders.texi
@@ -4089,6 +4089,10 @@ Quality-defined variable-bitrate.
Average variable bitrate.
@end table
+@item blbrc
+Enable block level rate control, which assigns different bitrate block by
block.
+Invalid for CQP mode.
+
@end table
Each encoder also has its own specific options:
diff --git a/libavcodec/vaapi_encode.c b/libavcodec/vaapi_encode.c
index 808b79c0c7..940f0678a5 100644
--- a/libavcodec/vaapi_encode.c
+++ b/libavcodec/vaapi_encode.c
@@ -1805,6 +1805,11 @@ static av_cold int
vaapi_encode_init_rate_control(AVCodecContext *avctx)
int i, first = 1, res;
supported_va_rc_modes = rc_attr.value;
+if (ctx->blbrc && !(supported_va_rc_modes & VA_RC_MB)) {
+ctx->blbrc = 0;
+av_log(avctx, AV_LOG_WARNING, "Driver does not support BLBRC.\n");
+}
+
for (i = 0; i < FF_ARRAY_ELEMS(vaapi_encode_rc_modes); i++) {
rc_mode = _encode_rc_modes[i];
if (supported_va_rc_modes & rc_mode->va_mode) {
@@ -2016,13 +2021,18 @@ rc_mode_found:
ctx->va_bit_rate = rc_bits_per_second;
av_log(avctx, AV_LOG_VERBOSE, "RC mode: %s.\n", rc_mode->name);
+
+if (ctx->blbrc && ctx->va_rc_mode == VA_RC_CQP)
+ctx->blbrc = 0;
+av_log(avctx, AV_LOG_VERBOSE, "Block Level bitrate control: %s.\n",
ctx->blbrc ? "ON" : "OFF");
+
if (rc_attr.value == VA_ATTRIB_NOT_SUPPORTED) {
// This driver does not want the RC mode attribute to be set.
} else {
ctx->config_attributes[ctx->nb_config_attributes++] =
(VAConfigAttrib) {
.type = VAConfigAttribRateControl,
-.value = ctx->va_rc_mode,
+.value = ctx->blbrc ? ctx->va_rc_mode | VA_RC_MB : ctx->va_rc_mode,
};
}
@@ -2051,6 +2061,7 @@ rc_mode_found:
#if VA_CHECK_VERSION(1, 1, 0)
.ICQ_quality_factor = av_clip(rc_quality, 1, 51),
.max_qp = (avctx->qmax > 0 ? avctx->qmax : 0),
+.rc_flags.bits.mb_rate_control = ctx->blbrc ? 1 : 2,
#endif
#if VA_CHECK_VERSION(1, 3, 0)
.quality_factor = rc_quality,
diff --git a/libavcodec/vaapi_encode.h b/libavcodec/vaapi_encode.h
index 6964055b93..0eed9691ca 100644
--- a/libavcodec/vaapi_encode.h
+++ b/libavcodec/vaapi_encode.h
@@ -216,6 +216,9 @@ typedef struct VAAPIEncodeContext {
// available modes).
int explicit_rc_mode;
+// Block Level based bitrate control.
+int blbrc;
+
// Explicitly-set QP, for use with the "qp" options.
// (Forces CQP mode when set, overriding everything else.)
int explicit_qp;
@@ -538,7 +541,11 @@ int ff_vaapi_encode_close(AVCodecContext *avctx);
VAAPI_ENCODE_RC_MODE(VBR, "Variable-bitrate"), \
VAAPI_ENCODE_RC_MODE(ICQ, "Intelligent constant-quality"), \
VAAPI_ENCODE_RC_MODE(QVBR, "Quality-defined variable-bitrate"), \
-VAAPI_ENCODE_RC_MODE(AVBR, "Average variable-bitrate")
+VAAPI_ENCODE_RC_MODE(AVBR, "Average variable-bitrate"), \
+{ "blbrc", \
+ "Block level based bitrate control",\
+ OFFSET(common.blbrc), AV_OPT_TYPE_BOOL, \
+ { .i64 = 0 }, 0, 1, FLAGS }
#endif /* AVCODEC_VAAPI_ENCODE_H */
--
2.25.1
___
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".
[FFmpeg-devel] [PATCH 2/2] libavcodec: Don't include libavcodec/x86/vvc/Makefile on any architecture
This currently builds files in the libavcodec/x86/{vvc,h26x}
subdirectories, which is somewhat unexpected when building for
another architecture than x86.
The regular arch subdirectories are handled with
-include $(SRC_PATH)/$(1)/$(ARCH)/Makefile
in the toplevel Makefile. Switch this to a similar optional
inclusion, using $(ARCH).
---
libavcodec/Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index 5d99120aa9..708434ac76 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -64,7 +64,7 @@ OBJS = ac3_parser.o
\
# subsystems
include $(SRC_PATH)/libavcodec/vvc/Makefile
-include $(SRC_PATH)/libavcodec/x86/vvc/Makefile
+-include $(SRC_PATH)/libavcodec/$(ARCH)/vvc/Makefile
OBJS-$(CONFIG_AANDCTTABLES)+= aandcttab.o
OBJS-$(CONFIG_AC3DSP) += ac3dsp.o ac3.o ac3tab.o
OBJS-$(CONFIG_ADTS_HEADER) += adts_header.o
mpeg4audio_sample_rates.o
--
2.39.3 (Apple Git-145)
___
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".
[FFmpeg-devel] [PATCH 1/2] makefile: Clean up missed object files with "make clean"
In some builds, the following object files could be left behind after make clean: ./libavfilter/metal/utils.o ./libavfilter/metal/vf_yadif_videotoolbox.metallib.o ./libavcodec/x86/h26x/h2656dsp.o ./libavcodec/neon/mpegvideo.o ./ffbuild/bin2c_host.o --- ffbuild/common.mak | 2 +- libavcodec/neon/Makefile| 3 +++ libavcodec/x86/vvc/Makefile | 2 +- libavfilter/Makefile| 1 + 4 files changed, 6 insertions(+), 2 deletions(-) diff --git a/ffbuild/common.mak b/ffbuild/common.mak index ac54ac0681..87a3ffd2b0 100644 --- a/ffbuild/common.mak +++ b/ffbuild/common.mak @@ -140,7 +140,7 @@ else endif clean:: - $(RM) $(BIN2CEXE) + $(RM) $(BIN2CEXE) $(CLEANSUFFIXES:%=ffbuild/%) %.c %.h %.pc %.ver %.version: TAG = GEN diff --git a/libavcodec/neon/Makefile b/libavcodec/neon/Makefile index 607f116a77..83c2f0051c 100644 --- a/libavcodec/neon/Makefile +++ b/libavcodec/neon/Makefile @@ -1 +1,4 @@ +clean:: + $(RM) $(CLEANSUFFIXES:%=libavcodec/neon/%) + OBJS-$(CONFIG_MPEGVIDEO) += neon/mpegvideo.o diff --git a/libavcodec/x86/vvc/Makefile b/libavcodec/x86/vvc/Makefile index 82f281d1c7..d1623bd46a 100644 --- a/libavcodec/x86/vvc/Makefile +++ b/libavcodec/x86/vvc/Makefile @@ -1,5 +1,5 @@ clean:: - $(RM) $(CLEANSUFFIXES:%=libavcodec/x86/vvc/%) + $(RM) $(CLEANSUFFIXES:%=libavcodec/x86/vvc/%) $(CLEANSUFFIXES:%=libavcodec/x86/h26x/%) OBJS-$(CONFIG_VVC_DECODER) += x86/vvc/vvcdsp_init.o \ x86/h26x/h2656dsp.o diff --git a/libavfilter/Makefile b/libavfilter/Makefile index f6c1d641d6..994d9773ba 100644 --- a/libavfilter/Makefile +++ b/libavfilter/Makefile @@ -666,6 +666,7 @@ TOOLS-$(CONFIG_LIBZMQ) += zmqsend clean:: $(RM) $(CLEANSUFFIXES:%=libavfilter/dnn/%) $(CLEANSUFFIXES:%=libavfilter/opencl/%) \ + $(CLEANSUFFIXES:%=libavfilter/metal/%) \ $(CLEANSUFFIXES:%=libavfilter/vulkan/%) OPENCL = $(subst $(SRC_PATH)/,,$(wildcard $(SRC_PATH)/libavfilter/opencl/*.cl)) -- 2.39.3 (Apple Git-145) ___ 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".
[FFmpeg-devel] [PATCH 3/3] lavc/thread.h: drop unnecessary includes
--- libavcodec/thread.h | 22 ++ 1 file changed, 10 insertions(+), 12 deletions(-) diff --git a/libavcodec/thread.h b/libavcodec/thread.h index 5a00b32619..111010b27f 100644 --- a/libavcodec/thread.h +++ b/libavcodec/thread.h @@ -27,11 +27,9 @@ #ifndef AVCODEC_THREAD_H #define AVCODEC_THREAD_H -#include "libavutil/buffer.h" +struct AVCodecContext; -#include "avcodec.h" - -int ff_thread_can_start_frame(AVCodecContext *avctx); +int ff_thread_can_start_frame(struct AVCodecContext *avctx); /** * If the codec defines update_thread_context(), call this @@ -41,14 +39,14 @@ int ff_thread_can_start_frame(AVCodecContext *avctx); * * @param avctx The context. */ -void ff_thread_finish_setup(AVCodecContext *avctx); +void ff_thread_finish_setup(struct AVCodecContext *avctx); -int ff_slice_thread_execute_with_mainfunc(AVCodecContext *avctx, -int (*action_func2)(AVCodecContext *c, void *arg, int jobnr, int threadnr), -int (*main_func)(AVCodecContext *c), void *arg, int *ret, int job_count); -int ff_slice_thread_allocz_entries(AVCodecContext *avctx, int count); -int ff_slice_thread_init_progress(AVCodecContext *avctx); -void ff_thread_report_progress2(AVCodecContext *avctx, int field, int thread, int n); -void ff_thread_await_progress2(AVCodecContext *avctx, int field, int thread, int shift); +int ff_slice_thread_execute_with_mainfunc(struct AVCodecContext *avctx, +int (*action_func2)(struct AVCodecContext *c, void *arg, int jobnr, int threadnr), +int (*main_func)(struct AVCodecContext *c), void *arg, int *ret, int job_count); +int ff_slice_thread_allocz_entries(struct AVCodecContext *avctx, int count); +int ff_slice_thread_init_progress(struct AVCodecContext *avctx); +void ff_thread_report_progress2(struct AVCodecContext *avctx, int field, int thread, int n); +void ff_thread_await_progress2(struct AVCodecContext *avctx, int field, int thread, int shift); #endif /* AVCODEC_THREAD_H */ -- 2.43.0 ___ 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".
[FFmpeg-devel] [PATCH 2/3] lavc: replace ff_thread_get_buffer() with ff_get_buffer()
ff_thread_get_buffer() has exactly the same semantics as
ff_get_buffer(), except it is supposed to be used in frame-threaded
decoders. Since the decoder instance knows whether frame threading is in
use, there is no point in forcing decoder implementations to use a
different function merely because they happen to support frame
threading.
---
libavcodec/aic.c | 4 ++--
libavcodec/alac.c | 4 ++--
libavcodec/av1dec.c | 2 +-
libavcodec/avcodec_internal.h | 13 +
libavcodec/bitpacked_dec.c| 4 ++--
libavcodec/cfhd.c | 4 ++--
libavcodec/cllc.c | 8
libavcodec/cri.c | 2 +-
libavcodec/decode.c | 13 -
libavcodec/dnxhddec.c | 2 +-
libavcodec/dvdec.c| 2 +-
libavcodec/dxtory.c | 12 ++--
libavcodec/dxv.c | 4 ++--
libavcodec/exr.c | 2 +-
libavcodec/flacdec.c | 4 ++--
libavcodec/fraps.c| 4 ++--
libavcodec/h264_slice.c | 2 +-
libavcodec/hapdec.c | 4 ++--
libavcodec/hdrdec.c | 2 +-
libavcodec/hevcdec.c | 2 +-
libavcodec/hqx.c | 4 ++--
libavcodec/huffyuvdec.c | 4 ++--
libavcodec/jpeg2000dec.c | 2 +-
libavcodec/lagarith.c | 12 ++--
libavcodec/lcldec.c | 4 ++--
libavcodec/magicyuv.c | 2 +-
libavcodec/mdec.c | 4 ++--
libavcodec/notchlc.c | 2 +-
libavcodec/photocd.c | 2 +-
libavcodec/pixlet.c | 2 +-
libavcodec/pngdec.c | 4 ++--
libavcodec/proresdec2.c | 2 +-
libavcodec/pthread_frame.c| 7 ++-
libavcodec/qoidec.c | 2 +-
libavcodec/rtv1.c | 2 +-
libavcodec/sheervideo.c | 4 ++--
libavcodec/takdec.c | 5 +++--
libavcodec/thread.h | 10 --
libavcodec/tiff.c | 2 +-
libavcodec/tta.c | 4 ++--
libavcodec/utils.c| 5 -
libavcodec/utvideodec.c | 4 ++--
libavcodec/v210dec.c | 4 ++--
libavcodec/v410dec.c | 4 ++--
libavcodec/vaapi_av1.c| 4 ++--
libavcodec/vble.c | 4 ++--
libavcodec/vmixdec.c | 2 +-
libavcodec/vvc/vvc_refs.c | 4 ++--
libavcodec/wbmpdec.c | 2 +-
libavcodec/webp.c | 2 +-
libavcodec/ylc.c | 4 ++--
51 files changed, 110 insertions(+), 103 deletions(-)
diff --git a/libavcodec/aic.c b/libavcodec/aic.c
index f8b0f60354..b4b5089228 100644
--- a/libavcodec/aic.c
+++ b/libavcodec/aic.c
@@ -27,10 +27,10 @@
#include "avcodec.h"
#include "bytestream.h"
#include "codec_internal.h"
+#include "decode.h"
#include "get_bits.h"
#include "golomb.h"
#include "idctdsp.h"
-#include "thread.h"
#include "unary.h"
#define AIC_HDR_SIZE24
@@ -408,7 +408,7 @@ static int aic_decode_frame(AVCodecContext *avctx, AVFrame
*frame,
return ret;
}
-if ((ret = ff_thread_get_buffer(avctx, ctx->frame, 0)) < 0)
+if ((ret = ff_get_buffer(avctx, ctx->frame, 0)) < 0)
return ret;
bytestream2_init(, buf + AIC_HDR_SIZE,
diff --git a/libavcodec/alac.c b/libavcodec/alac.c
index 538d1e5984..601d95a7f9 100644
--- a/libavcodec/alac.c
+++ b/libavcodec/alac.c
@@ -53,7 +53,7 @@
#include "get_bits.h"
#include "bytestream.h"
#include "codec_internal.h"
-#include "thread.h"
+#include "decode.h"
#include "unary.h"
#include "mathops.h"
#include "alac_data.h"
@@ -274,7 +274,7 @@ static int decode_element(AVCodecContext *avctx, AVFrame
*frame, int ch_index,
if (!alac->nb_samples) {
/* get output buffer */
frame->nb_samples = output_samples;
-if ((ret = ff_thread_get_buffer(avctx, frame, 0)) < 0)
+if ((ret = ff_get_buffer(avctx, frame, 0)) < 0)
return ret;
} else if (output_samples != alac->nb_samples) {
av_log(avctx, AV_LOG_ERROR, "sample count mismatch: %"PRIu32" != %d\n",
diff --git a/libavcodec/av1dec.c b/libavcodec/av1dec.c
index bbb5634773..98ef1e1935 100644
--- a/libavcodec/av1dec.c
+++ b/libavcodec/av1dec.c
@@ -899,7 +899,7 @@ static int av1_frame_alloc(AVCodecContext *avctx, AV1Frame
*f)
return ret;
}
-if ((ret = ff_thread_get_buffer(avctx, f->f, AV_GET_BUFFER_FLAG_REF)) < 0)
+if ((ret = ff_get_buffer(avctx, f->f, AV_GET_BUFFER_FLAG_REF)) < 0)
goto fail;
frame = f->f;
diff --git a/libavcodec/avcodec_internal.h b/libavcodec/avcodec_internal.h
index e7a229dee9..48fc813a73 100644
--- a/libavcodec/avcodec_internal.h
+++ b/libavcodec/avcodec_internal.h
@@ -58,6 +58,19 @@ struct AVCodecInternal *ff_encode_internal_alloc(void);
void ff_codec_close(struct AVCodecContext *avctx);
+/**
+ * Wrapper around AVCodecContext.get_buffer2(), called from pthread_frame when
+ * frame threading is active, from the ff_get_buffer() otherwise.
+ */
+int ff_decode_get_buffer(struct AVCodecContext *avctx,
[FFmpeg-devel] [PATCH 1/3] lavc/thread: move generic-layer API to avcodec_internal.h
thread.h currently contains both API for decoder use and functions internal to lavc generic layer. Move the latter to avcodec_internal.h, which is a more appropriate place for them. --- libavcodec/avcodec_internal.h | 24 libavcodec/pthread.c | 1 + libavcodec/thread.h | 25 + 3 files changed, 26 insertions(+), 24 deletions(-) diff --git a/libavcodec/avcodec_internal.h b/libavcodec/avcodec_internal.h index 4d1cb3a314..e7a229dee9 100644 --- a/libavcodec/avcodec_internal.h +++ b/libavcodec/avcodec_internal.h @@ -58,4 +58,28 @@ struct AVCodecInternal *ff_encode_internal_alloc(void); void ff_codec_close(struct AVCodecContext *avctx); +int ff_thread_init(struct AVCodecContext *s); +void ff_thread_free(struct AVCodecContext *s); + +/** + * Wait for decoding threads to finish and reset internal state. + * Called by avcodec_flush_buffers(). + * + * @param avctx The context. + */ +void ff_thread_flush(struct AVCodecContext *avctx); + +/** + * Submit a new frame to a decoding thread. + * Returns the next available frame in picture. *got_picture_ptr + * will be 0 if none is available. + * The return value on success is the size of the consumed packet for + * compatibility with FFCodec.decode. This means the decoder + * has to consume the full packet. + * + * Parameters are the same as FFCodec.decode. + */ +int ff_thread_decode_frame(struct AVCodecContext *avctx, struct AVFrame *frame, + int *got_picture_ptr, struct AVPacket *avpkt); + #endif // AVCODEC_AVCODEC_INTERNAL_H diff --git a/libavcodec/pthread.c b/libavcodec/pthread.c index ca84b81391..d32e56de0d 100644 --- a/libavcodec/pthread.c +++ b/libavcodec/pthread.c @@ -32,6 +32,7 @@ #include "libavutil/thread.h" #include "avcodec.h" +#include "avcodec_internal.h" #include "codec_internal.h" #include "pthread_internal.h" #include "thread.h" diff --git a/libavcodec/thread.h b/libavcodec/thread.h index f772d7ff18..4272fd87d4 100644 --- a/libavcodec/thread.h +++ b/libavcodec/thread.h @@ -20,7 +20,7 @@ /** * @file - * Multithreading support functions + * Multithreading API for decoders * @author Alexander Strange */ @@ -31,27 +31,6 @@ #include "avcodec.h" -/** - * Wait for decoding threads to finish and reset internal state. - * Called by avcodec_flush_buffers(). - * - * @param avctx The context. - */ -void ff_thread_flush(AVCodecContext *avctx); - -/** - * Submit a new frame to a decoding thread. - * Returns the next available frame in picture. *got_picture_ptr - * will be 0 if none is available. - * The return value on success is the size of the consumed packet for - * compatibility with FFCodec.decode. This means the decoder - * has to consume the full packet. - * - * Parameters are the same as FFCodec.decode. - */ -int ff_thread_decode_frame(AVCodecContext *avctx, AVFrame *picture, - int *got_picture_ptr, AVPacket *avpkt); - int ff_thread_can_start_frame(AVCodecContext *avctx); /** @@ -74,11 +53,9 @@ void ff_thread_finish_setup(AVCodecContext *avctx); */ int ff_thread_get_buffer(AVCodecContext *avctx, AVFrame *f, int flags); -int ff_thread_init(AVCodecContext *s); int ff_slice_thread_execute_with_mainfunc(AVCodecContext *avctx, int (*action_func2)(AVCodecContext *c, void *arg, int jobnr, int threadnr), int (*main_func)(AVCodecContext *c), void *arg, int *ret, int job_count); -void ff_thread_free(AVCodecContext *s); int ff_slice_thread_allocz_entries(AVCodecContext *avctx, int count); int ff_slice_thread_init_progress(AVCodecContext *avctx); void ff_thread_report_progress2(AVCodecContext *avctx, int field, int thread, int n); -- 2.43.0 ___ 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".
[FFmpeg-devel] [PATCH] libavdevice: Fix the avfoundation device after switching to FFInputFormat
This was missed in b800327f4c7233d09baca958121722a04c2035ff.
---
libavdevice/avfoundation.m | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/libavdevice/avfoundation.m b/libavdevice/avfoundation.m
index a0ef87edff..d9b17ccdae 100644
--- a/libavdevice/avfoundation.m
+++ b/libavdevice/avfoundation.m
@@ -32,6 +32,7 @@
#include "libavutil/pixdesc.h"
#include "libavutil/opt.h"
#include "libavutil/avstring.h"
+#include "libavformat/demux.h"
#include "libavformat/internal.h"
#include "libavutil/internal.h"
#include "libavutil/parseutils.h"
@@ -1292,13 +1293,13 @@ static int avf_close(AVFormatContext *s)
.category = AV_CLASS_CATEGORY_DEVICE_VIDEO_INPUT,
};
-const AVInputFormat ff_avfoundation_demuxer = {
-.name = "avfoundation",
-.long_name = NULL_IF_CONFIG_SMALL("AVFoundation input device"),
+const FFInputFormat ff_avfoundation_demuxer = {
+.p.name = "avfoundation",
+.p.long_name= NULL_IF_CONFIG_SMALL("AVFoundation input device"),
+.p.flags= AVFMT_NOFILE,
+.p.priv_class = _class,
.priv_data_size = sizeof(AVFContext),
.read_header= avf_read_header,
.read_packet= avf_read_packet,
.read_close = avf_close,
-.flags = AVFMT_NOFILE,
-.priv_class = _class,
};
--
2.39.3 (Apple Git-145)
___
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".
