Re: [FFmpeg-devel] [PATCH] avformat: deprecate AVFormatContext io_close callback
Quoting Marton Balint (2023-02-14 21:30:09) > > > On Tue, 14 Feb 2023, Anton Khirnov wrote: > > > Quoting Marton Balint (2023-02-13 22:37:54) > >> diff --git a/libavformat/version.h b/libavformat/version.h > >> index 904e7f06aa..7ff1483912 100644 > >> --- a/libavformat/version.h > >> +++ b/libavformat/version.h > >> @@ -31,7 +31,7 @@ > >> > >> #include "version_major.h" > >> > >> -#define LIBAVFORMAT_VERSION_MINOR 2 > >> +#define LIBAVFORMAT_VERSION_MINOR 3 > > > > I don't think this needs a version bump, because nothing about the API > > or ABI changes with this commit, it's just an expression of intent to > > change it in the future. > > My concern with not increasing the version number is that the entry in > doc/APIChanges will not point to the version where the change happened... I don't see that as a problem, because the relevant question from the user perspective is "in what version was the replacement for added" rather than "in what version was deprecated", since one should always use the newer API when it is present. -- 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] configure: select subordinate formats for HLS
On 2023-02-14 02:16 pm, Gyan Doshi wrote: On 2023-02-11 06:06 pm, Gyan Doshi wrote: HLS segments may be MPEG-TS or fragmented MP4, so those (de)muxers are required for reading/writing HLS media segments. Fixes functionality with --disable-everything --enable-demuxer=hls --enable-muxer=hls Comments? Plan to push tomorrow. Regards, Gyan --- configure | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/configure b/configure index d38613309d..2f1771c336 100755 --- a/configure +++ b/configure @@ -3436,8 +3436,8 @@ flac_demuxer_select="flac_parser" flv_muxer_select="aac_adtstoasc_bsf" gxf_muxer_select="pcm_rechunk_bsf" hds_muxer_select="flv_muxer" -hls_demuxer_select="adts_header ac3_parser" -hls_muxer_select="mpegts_muxer" +hls_demuxer_select="adts_header ac3_parser mov_demuxer mpegts_demuxer" +hls_muxer_select="mov_muxer mpegts_muxer" hls_muxer_suggest="gcrypt openssl" image2_alias_pix_demuxer_select="image2_demuxer" image2_brender_pix_demuxer_select="image2_demuxer" ___ 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".
[FFmpeg-devel] [PATCH] avformat/cdg: add probe
Patch attached.
From b0cd65c70465da729d950dfff1c20129e81462fc Mon Sep 17 00:00:00 2001
From: Paul B Mahol
Date: Tue, 14 Feb 2023 22:25:42 +0100
Subject: [PATCH] avformat/cdg: add probe
Signed-off-by: Paul B Mahol
---
libavformat/cdg.c | 17 +
1 file changed, 17 insertions(+)
diff --git a/libavformat/cdg.c b/libavformat/cdg.c
index 36f25e7f66..f598285911 100644
--- a/libavformat/cdg.c
+++ b/libavformat/cdg.c
@@ -26,6 +26,22 @@
#define CDG_COMMAND0x09
#define CDG_MASK 0x3F
+static int read_probe(const AVProbeData *p)
+{
+const int cnt = p->buf_size / CDG_PACKET_SIZE;
+int score = 0;
+
+for (int i = 0; i < cnt; i++) {
+const int x = p->buf[i * CDG_PACKET_SIZE] & CDG_MASK;
+
+score += x == CDG_COMMAND;
+if (x != CDG_COMMAND && x != 0)
+return 0;
+}
+
+return FFMIN(score, AVPROBE_SCORE_MAX);
+}
+
static int read_header(AVFormatContext *s)
{
AVStream *vst;
@@ -70,6 +86,7 @@ static int read_packet(AVFormatContext *s, AVPacket *pkt)
const AVInputFormat ff_cdg_demuxer = {
.name = "cdg",
.long_name = NULL_IF_CONFIG_SMALL("CD Graphics"),
+.read_probe = read_probe,
.read_header= read_header,
.read_packet= read_packet,
.flags = AVFMT_GENERIC_INDEX,
--
2.39.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] avformat: deprecate AVFormatContext io_close callback
On Tue, 14 Feb 2023, Anton Khirnov wrote: Quoting Marton Balint (2023-02-13 22:37:54) diff --git a/libavformat/version.h b/libavformat/version.h index 904e7f06aa..7ff1483912 100644 --- a/libavformat/version.h +++ b/libavformat/version.h @@ -31,7 +31,7 @@ #include "version_major.h" -#define LIBAVFORMAT_VERSION_MINOR 2 +#define LIBAVFORMAT_VERSION_MINOR 3 I don't think this needs a version bump, because nothing about the API or ABI changes with this commit, it's just an expression of intent to change it in the future. My concern with not increasing the version number is that the entry in doc/APIChanges will not point to the version where the change happened... 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".
Re: [FFmpeg-devel] [PATCH] avformat/movenc: allow writing out channel count in MP4 and 3GP
On Thu, Feb 9, 2023 at 9:24 PM Jan Ekström wrote:
>
> On Thu, Feb 9, 2023 at 12:08 PM Martin Storsjö wrote:
> >
> > This looks reasonable to me. I didn't follow the references in the commit
> > message, but it sounds plausible and probably correct to me.
> >
>
> For the record, due to dumb ISO/IEC rule changes regarding how
> specifications need to be authorized to be free after 2015, it's
> relatively hard to verify the 14496-12 part.
>
> The last version of 14496-12 that was freely available (2015) defined
> channelcount in AudioSampleEntry as follows:
>
> template unsigned int(16) channelcount = 2;
>
> Meanwhile the latest 2022 edition defines the related structure(s) as follows:
>
> class AudioSampleEntry(codingname) extends SampleEntry (codingname) {
>const unsigned int(32)[2] reserved = 0;
>unsigned int(16) channelcount;
>template unsigned int(16) samplesize = 16;
>unsigned int(16) pre_defined = 0;
>const unsigned int(16) reserved = 0 ;
>template unsigned int(32) samplerate = { default samplerate of media} <<
> 16;
>// optional boxes follow
>Box (); // further boxes as needed
>ChannelLayout();
>DownMixInstructions() [];
>DRCCoefficientsBasic() [];
>DRCInstructionsBasic() [];
>DRCCoefficientsUniDRC() [];
>DRCInstructionsUniDRC() [];
>// we permit only one DRC Extension box:
>UniDrcConfigExtension();
>// optional boxes follow
>SamplingRateBox();
>ChannelLayout();
> }
>
> aligned(8) class SamplingRateBox extends FullBox('srat') {
>unsigned int(32) sampling_rate;
> }
>
> class AudioSampleEntryV1(codingname) extends SampleEntry (codingname) {
>unsigned int(16) entry_version; // shall be 1,
> // and shall be in an stsd with version ==1
>const unsigned int(16)[3] reserved = 0;
>template unsigned int(16) channelcount; // shall be correct
>template unsigned int(16) samplesize = 16;
>unsigned int(16) pre_defined = 0;
>const unsigned int(16) reserved = 0 ;
>template unsigned int(32) samplerate = 1<<16;
>// optional boxes follow
>SamplingRateBox();
>Box (); // further boxes as needed
>ChannelLayout();
>DownMixInstructions() [];
>DRCCoefficientsBasic() [];
>DRCInstructionsBasic() [];
>DRCCoefficientsUniDRC() [];
>DRCInstructionsUniDRC() [];
>// we permit only one DRC Extension box:
>UniDrcConfigExtension();
>// optional boxes follow
>ChannelLayout();
> }
Applied to master as 02ddfeadbee52c1ad8c023a93594a8cb957e11db .
Jan
___
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] Proposed change to NVDEC ulNumOutputSurfaces initialization
On 14.02.2023 18:27, Miller, Adrian wrote:
Hi,
I'm considering a proposing a change to libavcodec/nvdec.c but wanted to run it
by you first as I'm new to FFmpeg development to make sure I've gotten things
right (this is not a patch).
We use the NVDEC decoder as part of our live transcoder. This means that new decoders may be
spun up to accommodate switching sources but the frames_ctx->initial_pool_size is
calculated based on values from the source's initial SPS and the decoder's
"extra_hw_frames" option, so it's possible that a new source will result in an
SPS+extra_hw_frames value greater than the max supported by the NVDEC decoder, 32.
The current behavior is to return if the NVDEC decoder fails to initialize and
return a warning (nvdec.c:413). I'm sure this is fine in the interactive use
case where the user can simply provide a smaller value for extra_hw_frames and
try again. In the unattended case this isn't possible, and our application
fails.
I was thinking something along the lines of in nvdec.c to handle this case:
-params.ulNumDecodeSurfaces = frames_ctx->initial_pool_size;
-params.ulNumOutputSurfaces = frames_ctx->initial_pool_size;
+const int kMaxSurfaces = 32;
+params.ulNumDecodeSurfaces = (frames_ctx->initial_pool_size <= kMaxSurfaces)
? frames_ctx->initial_pool_size : kMaxSurfaces;
+params.ulNumOutputSurfaces = params.ulNumDecodeSurfaces;
+if (frames_ctx->initial_pool_size > kMaxSurfaces) {
+av_log(avctx, AV_LOG_WARNING, "Requested %d decode surfaces, which is more
than %d. Condifuring decoder with %d surfaces.\n",
+ (int)frames_ctx->initial_pool_size, kMaxSurfaces,
(int)params.ulNumDecodeSurfaces);
+}
Plus, probably rewording the original warning that handles the case where the
decoder still fails.
Thoughts? If this seems like a reasonable approach I'll put together a formal
patch email after going through the rest of your submission process and the
stuff I have to do for my employer.
Something like that seems reasonable enough to me for sure.
Better than running into a failure right away.
Make sure to limit the number of threads in your setup.
Those are the main source for extra surfaces, specially on systems with
high CPU/thread numbers.
If all you do is hwdecode/process/encode, you can safely just set the
threads value to two and call it a day, and you'll then likely never run
into the limit again.
___
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 v14 9/9] avcodec/evc: Changes in Changelog and MAINTAINERS files
On Tue, 14 Feb 2023 at 12:10, Dawid Kozinski/Multimedia (PLT) /SRPOL/Staff Engineer/Samsung Electronics wrote: > > At the moment, it doesn't matter to us whether there are two lists or one. > What matters to us is pushing our patchset containing an EVC codec wrapper > to ffmpeg. We want to refine and maintain this code and have the > information > somewhere about who is responsible for it (EVC) and who to contact with > questions. We hope that our patchset will eventually be accepted, and we > will then apply for write access to Git because we want to take care of the > EVC code. > I appreciate your sincerity but history shows that patches to third-party libs from corporate contributors are not maintained (as Ronald said). People change jobs, work focus changes etc etc. A good example of this is libyami. Even more so for EVC which has had very limited uptake. Regards, Kieran Kunhya ___ 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 v14 9/9] avcodec/evc: Changes in Changelog and MAINTAINERS files
Feb 14, 2023, 13:10 by d.kozin...@samsung.com: > > -Original Message- > From: ffmpeg-devel On Behalf Of Lynne > Sent: poniedziałek, 13 lutego 2023 18:32 > To: FFmpeg development discussions and patches > Subject: Re: [FFmpeg-devel] [PATCH v14 9/9] avcodec/evc: Changes in > Changelog and MAINTAINERS files > > Feb 13, 2023, 10:29 by d.kozin...@samsung.com: > >> Lynne, if it concerns us, we will comply with both the current and the >> new maintainership policy once your patchset is pushed. We see that >> your change has not yet been pushed into the main branch, and it >> appears that the discussion on this topic may still be ongoing, >> although both Michael and other maintainers have reviewed and commented on >> > it. > >> >> > > What do you mean both current and new policy? > > Lynne, you mentioned a new policy change on maintainership in one of the > previous emails: > "I assign myself to personally review the patchset and push it, if you > review my policy change on maintainership. As I said, I have no objection on > who gets maintainership, just that it is done explicitly via a separate list > in the maintainers file." > Fair enough, I'll just review the patchset while ignoring this patch. ___ 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] Proposed change to NVDEC ulNumOutputSurfaces initialization
Hi,
I'm considering a proposing a change to libavcodec/nvdec.c but wanted to run it
by you first as I'm new to FFmpeg development to make sure I've gotten things
right (this is not a patch).
We use the NVDEC decoder as part of our live transcoder. This means that new
decoders may be spun up to accommodate switching sources but the
frames_ctx->initial_pool_size is calculated based on values from the source's
initial SPS and the decoder's "extra_hw_frames" option, so it's possible that a
new source will result in an SPS+extra_hw_frames value greater than the max
supported by the NVDEC decoder, 32.
The current behavior is to return if the NVDEC decoder fails to initialize and
return a warning (nvdec.c:413). I'm sure this is fine in the interactive use
case where the user can simply provide a smaller value for extra_hw_frames and
try again. In the unattended case this isn't possible, and our application
fails.
I was thinking something along the lines of in nvdec.c to handle this case:
-params.ulNumDecodeSurfaces = frames_ctx->initial_pool_size;
-params.ulNumOutputSurfaces = frames_ctx->initial_pool_size;
+const int kMaxSurfaces = 32;
+params.ulNumDecodeSurfaces = (frames_ctx->initial_pool_size <=
kMaxSurfaces) ? frames_ctx->initial_pool_size : kMaxSurfaces;
+params.ulNumOutputSurfaces = params.ulNumDecodeSurfaces;
+if (frames_ctx->initial_pool_size > kMaxSurfaces) {
+av_log(avctx, AV_LOG_WARNING, "Requested %d decode surfaces, which is
more than %d. Condifuring decoder with %d surfaces.\n",
+ (int)frames_ctx->initial_pool_size, kMaxSurfaces,
(int)params.ulNumDecodeSurfaces);
+}
Plus, probably rewording the original warning that handles the case where the
decoder still fails.
Thoughts? If this seems like a reasonable approach I'll put together a formal
patch email after going through the rest of your submission process and the
stuff I have to do for my employer.
Thanks,
Ade Miller
___
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] vf_yadif: Remove unused emms_c
Quoting Kieran Kunhya (2023-02-10 23:47:52) > $subj > > Probably others as well > > From 272459245d872e49bd8908561dd2727e40f7d6da Mon Sep 17 00:00:00 2001 > From: Kieran Kunhya > Date: Fri, 10 Feb 2023 22:46:03 + > Subject: [PATCH] vf_yadif: Remove unused emms_c > > --- > libavfilter/vf_yadif.c | 2 -- > 1 file changed, 2 deletions(-) > > diff --git a/libavfilter/vf_yadif.c b/libavfilter/vf_yadif.c > index 1f9434f961..3d0368edb9 100644 > --- a/libavfilter/vf_yadif.c > +++ b/libavfilter/vf_yadif.c > @@ -252,8 +252,6 @@ static void filter(AVFilterContext *ctx, AVFrame *dstpic, > ff_filter_execute(ctx, filter_slice, &td, NULL, >FFMIN(h, ff_filter_get_nb_threads(ctx))); > } > - > -emms_c(); looks ok -- 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: deprecate AVFormatContext io_close callback
Quoting Marton Balint (2023-02-13 22:37:54) > diff --git a/libavformat/version.h b/libavformat/version.h > index 904e7f06aa..7ff1483912 100644 > --- a/libavformat/version.h > +++ b/libavformat/version.h > @@ -31,7 +31,7 @@ > > #include "version_major.h" > > -#define LIBAVFORMAT_VERSION_MINOR 2 > +#define LIBAVFORMAT_VERSION_MINOR 3 I don't think this needs a version bump, because nothing about the API or ABI changes with this commit, it's just an expression of intent to change it in the future. Otherwise LGTM. -- 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/flvenc: allow to write qualifying metadata as number
On 2023-02-14 03:35 pm, Anton Khirnov wrote: Quoting Gyan Doshi (2023-02-11 12:02:51) The FLV format can store metadata as numbers which are used and handled by many streaming platforms. Now, metadata values can be sent as AMF Number type if 1) tag key starts with "num_" 2) value is scanned and can be represented as a double. Written tag will have "num_" prefix removed if written as AMF Number. Using the normal metadata dict for structured data seems hacky to me. Wouldn't it be better to add a private dict-type muxer option for this? The numerical metadata, like other string meta in FLV can change during streaming, so it will be reloaded and refreshed. Once you suggested to shift the loading metadata from file + reload options to fftools, this was the way to identify such metadata, since format contexts and AVStream only support one AVDictionary and entries will have to be commingled And this isn't really structured data. We are re-encoding how some of it is stored. It is still inputted by the user as strings. The prefix is a cheap hack to clearly identify such keys. (The other option would be add AVDictionary value 'types' and all associated signalling and tooling, which seems useful in the long run but overkill for this.) Regards, Gyan ___ 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] avutil: [LA] use getauxval to do runtime check.
Replace cpucfg with getauxval to avoid crash in case of
some processor capabilities are not supportted by kernel used.
---
libavutil/loongarch/cpu.c | 24
1 file changed, 8 insertions(+), 16 deletions(-)
diff --git a/libavutil/loongarch/cpu.c b/libavutil/loongarch/cpu.c
index e4b240bc44..cad8504fde 100644
--- a/libavutil/loongarch/cpu.c
+++ b/libavutil/loongarch/cpu.c
@@ -21,26 +21,18 @@
#include
#include "cpu.h"
+#include
-#define LOONGARCH_CFG2 0x2
-#define LOONGARCH_CFG2_LSX(1 << 6)
-#define LOONGARCH_CFG2_LASX (1 << 7)
-
-static int cpu_flags_cpucfg(void)
+#define LA_HWCAP_LSX(1<<4)
+#define LA_HWCAP_LASX (1<<5)
+static int cpu_flags_getauxval(void)
{
int flags = 0;
-uint32_t cfg2 = 0;
-
-__asm__ volatile(
-"cpucfg %0, %1 \n\t"
-: "+&r"(cfg2)
-: "r"(LOONGARCH_CFG2)
-);
+int flag = (int)getauxval(AT_HWCAP);
-if (cfg2 & LOONGARCH_CFG2_LSX)
+if (flag & LA_HWCAP_LSX)
flags |= AV_CPU_FLAG_LSX;
-
-if (cfg2 & LOONGARCH_CFG2_LASX)
+if (flag & LA_HWCAP_LASX)
flags |= AV_CPU_FLAG_LASX;
return flags;
@@ -49,7 +41,7 @@ static int cpu_flags_cpucfg(void)
int ff_get_cpu_flags_loongarch(void)
{
#if defined __linux__
-return cpu_flags_cpucfg();
+return cpu_flags_getauxval();
#else
/* Assume no SIMD ASE supported */
return 0;
--
2.20.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 v14 9/9] avcodec/evc: Changes in Changelog and MAINTAINERS files
-Original Message-
From: ffmpeg-devel On Behalf Of Lynne
Sent: poniedziałek, 13 lutego 2023 18:32
To: FFmpeg development discussions and patches
Subject: Re: [FFmpeg-devel] [PATCH v14 9/9] avcodec/evc: Changes in
Changelog and MAINTAINERS files
Feb 13, 2023, 10:29 by d.kozin...@samsung.com:
> Lynne, if it concerns us, we will comply with both the current and the
> new maintainership policy once your patchset is pushed. We see that
> your change has not yet been pushed into the main branch, and it
> appears that the discussion on this topic may still be ongoing,
> although both Michael and other maintainers have reviewed and commented on
it.
>
What do you mean both current and new policy?
Lynne, you mentioned a new policy change on maintainership in one of the
previous emails:
"I assign myself to personally review the patchset and push it, if you
review my policy change on maintainership. As I said, I have no objection on
who gets maintainership, just that it is done explicitly via a separate list
in the maintainers file."
New Policy
==
Your proposal is for a separate list of developers who have write access to
the GIT repository [new policy]
(https://patchwork.ffmpeg.org/project/ffmpeg/patch/njil3bf--...@lynne.ee/)
Current Policy
==
Currently, the MAINTAINERS file has one list of developers who may or may
not have write access. The MAINTAINERS file currently contains one list of
developers who may or may not have write access to the GIT.
Unfortunately, there are significant discrepancies regarding who should be
on this list and what rights they should have:
Some ffmpeg maintainers argue that those on the list may not necessarily
have write access but may qualify for access to publish changes. Being on
this list gives them the right to reject (negative acknowledgement - NAK) a
set of changes related to the module they are responsible for and (ideally)
requires their approval before making any changes to the module.
Others, like Lynne, believe that the list should only exist for those who
have write access ("... that list is only for those with push access"). Only
developers who have contributed to the project and understand that
maintaining a repository requires a certain level of dedication should be
included on the list.
There are also those who believe that developers who care about a piece of
code should have write access if they ask for it. Each developer who takes
care of a bit of the code base (reviewing patches, approving them, fixing
issues, adding features, ...) has the same rights as others.
At the moment, it doesn't matter to us whether there are two lists or one.
What matters to us is pushing our patchset containing an EVC codec wrapper
to ffmpeg. We want to refine and maintain this code and have the information
somewhere about who is responsible for it (EVC) and who to contact with
questions. We hope that our patchset will eventually be accepted, and we
will then apply for write access to Git because we want to take care of the
EVC code.
We would like to separate these 2 topics, the mainteiners list and the EVC
patch.
At this point our patch seems to be in line with the current policy.
If anyone has any comments regarding a particular MAINTENANCE file related
to our patchset, please make comments.
Our EVC patch does not change MAINTENANCE policy.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://protect2.fireeye.com/v1/url?k=9790493d-f61b5c0e-9791c272-000babff9bb
7-cf6035a5089c4d08&q=1&e=1d26169f-514c-456d-9439-ef58a866852d&u=https%3A%2F%
2Fffmpeg.org%2Fmailman%2Flistinfo%2Fffmpeg-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 v5 01/10] lavc/avcodec: Add HEVC Screen Content Coding Extensions profile
Quoting Fei Wang (2023-02-06 06:44:49)
> From: Linjie Fu
>
> Described in HEVC spec A.3.7.
>
> Signed-off-by: Linjie Fu
> Signed-off-by: Fei Wang
> ---
> 1. fix compile warning with VAAPI version less than 1.2.0
>
> libavcodec/avcodec.h | 1 +
> libavcodec/hevc_ps.c | 2 ++
> libavcodec/profiles.c | 1 +
> 3 files changed, 4 insertions(+)
>
> diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
> index 90b437ccbe..9e36d2402a 100644
> --- a/libavcodec/avcodec.h
> +++ b/libavcodec/avcodec.h
> @@ -1672,6 +1672,7 @@ typedef struct AVCodecContext {
> #define FF_PROFILE_HEVC_MAIN_10 2
> #define FF_PROFILE_HEVC_MAIN_STILL_PICTURE 3
> #define FF_PROFILE_HEVC_REXT4
> +#define FF_PROFILE_HEVC_SCC 9
This is an API addition and so needs a minor bump and an entry in
APIchanges
--
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/flvenc: allow to write qualifying metadata as number
Quoting Gyan Doshi (2023-02-11 12:02:51) > The FLV format can store metadata as numbers which are used and handled > by many streaming platforms. > > Now, metadata values can be sent as AMF Number type if > 1) tag key starts with "num_" > 2) value is scanned and can be represented as a double. > > Written tag will have "num_" prefix removed if written as AMF Number. Using the normal metadata dict for structured data seems hacky to me. Wouldn't it be better to add a private dict-type muxer option for this? -- 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".
[FFmpeg-devel] [PATCH] libavcodec/hevc: add hevc idct_4x4_neon of aarch64
---
libavcodec/aarch64/hevcdsp_idct_neon.S| 51 +++
libavcodec/aarch64/hevcdsp_init_aarch64.c | 4 ++
2 files changed, 55 insertions(+)
diff --git a/libavcodec/aarch64/hevcdsp_idct_neon.S
b/libavcodec/aarch64/hevcdsp_idct_neon.S
index 124c50998a..fe8baf1348 100644
--- a/libavcodec/aarch64/hevcdsp_idct_neon.S
+++ b/libavcodec/aarch64/hevcdsp_idct_neon.S
@@ -245,6 +245,54 @@ function hevc_add_residual_32x32_16_neon, export=0
ret
endfunc
+.macro tr_4x4 in0, in1, in2, in3, out0, out1, out2, out3, shift, tmp0, tmp1,
tmp2, tmp3, tmp4
+ sshll \tmp0, \in0, #6
+ smull \tmp2, \in1, v4.h[1]
+ mov\tmp1, \tmp0
+ smull \tmp3, \in1, v4.h[3]
+ smlal \tmp0, \in2, v4.h[0] //e0
+ smlsl \tmp1, \in2, v4.h[0] //e1
+ smlal \tmp2, \in3, v4.h[3] //o0
+ smlsl \tmp3, \in3, v4.h[1] //o1
+
+ add\tmp4, \tmp0, \tmp2
+ sub\tmp0, \tmp0, \tmp2
+ add\tmp2, \tmp1, \tmp3
+ sub\tmp1, \tmp1, \tmp3
+ sqrshrn\out0, \tmp4, #\shift
+ sqrshrn\out3, \tmp0, #\shift
+ sqrshrn\out1, \tmp2, #\shift
+ sqrshrn\out2, \tmp1, #\shift
+.endm
+
+.macro transpose_4x4 r0, r1, r2, r3
+trn1v22.8h, \r0\().8h, \r1\().8h
+trn2v23.8h, \r0\().8h, \r1\().8h
+trn1v24.8h, \r2\().8h, \r3\().8h
+trn2v25.8h, \r2\().8h, \r3\().8h
+trn1\r0\().4s, v22.4s, v24.4s
+trn2\r2\().4s, v22.4s, v24.4s
+trn1\r1\().4s, v23.4s, v25.4s
+trn2\r3\().4s, v23.4s, v25.4s
+.endm
+
+.macro idct_4x4 bitdepth
+function ff_hevc_idct_4x4_\bitdepth\()_neon, export=1
+ld1 {v0.4h-v3.4h}, [x0]
+
+movrel x1, trans
+ld1 {v4.4h}, [x1]
+
+tr_4x4 v0.4h, v1.4h, v2.4h, v3.4h, v16.4h, v17.4h, v18.4h,
v19.4h, 7, v10.4s, v11.4s, v12.4s, v13.4s, v15.4s
+transpose_4x4 v16, v17, v18, v19
+
+tr_4x4 v16.4h, v17.4h, v18.4h, v19.4h, v0.4h, v1.4h, v2.4h,
v3.4h, 20 - \bitdepth, v10.4s, v11.4s, v12.4s, v13.4s, v15.4s
+transpose_4x4 v0, v1, v2, v3
+st1 {v0.4h-v3.4h}, [x0]
+ret
+endfunc
+.endm
+
.macro sum_sub out, in, c, op, p
.ifc \op, +
smlal\p \out, \in, \c
@@ -578,6 +626,9 @@ function ff_hevc_idct_16x16_\bitdepth\()_neon, export=1
endfunc
.endm
+idct_4x4 8
+idct_4x4 10
+
idct_8x8 8
idct_8x8 10
diff --git a/libavcodec/aarch64/hevcdsp_init_aarch64.c
b/libavcodec/aarch64/hevcdsp_init_aarch64.c
index 88a797f393..1deefca0a2 100644
--- a/libavcodec/aarch64/hevcdsp_init_aarch64.c
+++ b/libavcodec/aarch64/hevcdsp_init_aarch64.c
@@ -49,6 +49,8 @@ void ff_hevc_add_residual_32x32_10_neon(uint8_t *_dst, const
int16_t *coeffs,
ptrdiff_t stride);
void ff_hevc_add_residual_32x32_12_neon(uint8_t *_dst, const int16_t *coeffs,
ptrdiff_t stride);
+void ff_hevc_idct_4x4_8_neon(int16_t *coeffs, int col_limit);
+void ff_hevc_idct_4x4_10_neon(int16_t *coeffs, int col_limit);
void ff_hevc_idct_8x8_8_neon(int16_t *coeffs, int col_limit);
void ff_hevc_idct_8x8_10_neon(int16_t *coeffs, int col_limit);
void ff_hevc_idct_16x16_8_neon(int16_t *coeffs, int col_limit);
@@ -119,6 +121,7 @@ av_cold void ff_hevc_dsp_init_aarch64(HEVCDSPContext *c,
const int bit_depth)
c->add_residual[1] = ff_hevc_add_residual_8x8_8_neon;
c->add_residual[2] = ff_hevc_add_residual_16x16_8_neon;
c->add_residual[3] = ff_hevc_add_residual_32x32_8_neon;
+c->idct[0] = ff_hevc_idct_4x4_8_neon;
c->idct[1] = ff_hevc_idct_8x8_8_neon;
c->idct[2] = ff_hevc_idct_16x16_8_neon;
c->idct_dc[0] = ff_hevc_idct_4x4_dc_8_neon;
@@ -168,6 +171,7 @@ av_cold void ff_hevc_dsp_init_aarch64(HEVCDSPContext *c,
const int bit_depth)
c->add_residual[1] = ff_hevc_add_residual_8x8_10_neon;
c->add_residual[2] = ff_hevc_add_residual_16x16_10_neon;
c->add_residual[3] = ff_hevc_add_residual_32x32_10_neon;
+c->idct[0] = ff_hevc_idct_4x4_10_neon;
c->idct[1] = ff_hevc_idct_8x8_10_neon;
c->idct[2] = ff_hevc_idct_16x16_10_neon;
c->idct_dc[0] = ff_hevc_idct_4x4_dc_10_neon;
--
2.32.0 (Apple Git-132)
___
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] lavf/mxfenc: Bump EDIT_UNITS_PER_BODY
mån 2023-02-13 klockan 22:05 +0100 skrev Marton Balint:
>
> I think we have a pretty good idea that MPEG2 in MXF usually means
> some
> broadcast realted use, therefore intent of RDD9 compliance by default
> is
> not insane at all for MPEG2 essence. Can we please keep it as default
> for
> MPEG2?
If the intent is to follow RDD9 then more things need to be done, among
them erroring out if gop_size > 15. EDIT_UNITS_PER_BODY is also too big
for 24/1.001 Hz essence. Finally the logic around line 2988 is wrong
since it will easily and consistently writes index table segments > 10
seconds:
> if (!mxf->edit_unit_byte_count &&
> (!mxf->edit_units_count || mxf->edit_units_count >
> EDIT_UNITS_PER_BODY) &&
> !(ie.flags & 0x33)) { // I-frame, GOP start
>
This will only work for NTSC because (250+15)/30*1.001 < 8.9s
assuming gop_size <= 15, and it will be > 10s for PAL and 24/1.001 Hz.
The reallocation logic is likely there to compensate for this
wrongness.
The simplest way to remain compliant should therefore be:
* check that gop_size <= 15
* change the above condition to mxf->edit_units_count > 239-gop_size
(maybe -1)
The simplest for the latter is just > 223. If ever the muxer gets a
series of packages that then exceeds the limits set out in RDD 9-2006
then it should complain loudly and terminate so that users don't
accidentally write non-compliant files.
For the allocation stuff, we should make room for 301 EditUnits. If
ever the muxer finds the need to insert a 302nd EditUnit when muxing
MPEG2 then it should error out.
Of course a lot of this could likely be avoided if we just used BMX
instead.
>
> >
> > >
> > > There is also code which allocates the index entries in
> > > EDIT_UNITS_PER_BODY increments, that probably should be replaced
> > > with
> > > av_dynarray2_add...
> >
> > That (re)allocation happens at most twice for assuming GOP size <
> > EDIT_UNITS_PER_BODY
> >
> > The reason I bring this all up is because opening MXF files muxed
> > by
> > lavf over HTTP is slow as hell. This will be true for any other
> > storage
> > where seeking incurs a non-trivial cost. HDDs come to mind. Perhaps
> > that is really an mxfdec problem, but then parsing becomes even
> > hairier
> > than it already is. We'd have to binary search the file when
> > seeking,
> > hoping to find the necessary index table segments on-the-fly..
>
> A sane muxer duplicates all index table segments in the footer, so a
> smart
> demuxer can read the whole index from there.
True, though that requires using a dynarray. It also requires smarts
that I don't think mxfdec currently has.
> Yes, mxfdec problem. I have a
> WIP patch somewhere fixing that.
That would be lovely
/Tomas
___
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] configure: select subordinate formats for HLS
On 2023-02-11 06:06 pm, Gyan Doshi wrote: HLS segments may be MPEG-TS or fragmented MP4, so those (de)muxers are required for reading/writing HLS media segments. Fixes functionality with --disable-everything --enable-demuxer=hls --enable-muxer=hls Comments? --- configure | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/configure b/configure index d38613309d..2f1771c336 100755 --- a/configure +++ b/configure @@ -3436,8 +3436,8 @@ flac_demuxer_select="flac_parser" flv_muxer_select="aac_adtstoasc_bsf" gxf_muxer_select="pcm_rechunk_bsf" hds_muxer_select="flv_muxer" -hls_demuxer_select="adts_header ac3_parser" -hls_muxer_select="mpegts_muxer" +hls_demuxer_select="adts_header ac3_parser mov_demuxer mpegts_demuxer" +hls_muxer_select="mov_muxer mpegts_muxer" hls_muxer_suggest="gcrypt openssl" image2_alias_pix_demuxer_select="image2_demuxer" image2_brender_pix_demuxer_select="image2_demuxer" ___ 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/flvenc: allow to write qualifying metadata as number
On 2023-02-11 04:32 pm, Gyan Doshi wrote:
The FLV format can store metadata as numbers which are used and handled
by many streaming platforms.
Now, metadata values can be sent as AMF Number type if
1) tag key starts with "num_"
2) value is scanned and can be represented as a double.
Written tag will have "num_" prefix removed if written as AMF Number.
Comments?
---
doc/muxers.texi | 2 ++
libavformat/flvenc.c | 33 -
2 files changed, 30 insertions(+), 5 deletions(-)
diff --git a/doc/muxers.texi b/doc/muxers.texi
index ed5341be39..c9bafeec19 100644
--- a/doc/muxers.texi
+++ b/doc/muxers.texi
@@ -509,6 +509,8 @@ ffmpeg -re -i ... -c:v libx264 -c:a aac -f fifo
-fifo_format flv -map 0:v -map 0
@section flv
Adobe Flash Video Format muxer.
+This muxer will store user metadata whose keys start with @code{num_} and
whose value is identified as a
+pure value of type double as an AMF Number. All other user metadata is stored
as a String.
This muxer accepts the following options:
diff --git a/libavformat/flvenc.c b/libavformat/flvenc.c
index 81d9b6100d..25d09ef304 100644
--- a/libavformat/flvenc.c
+++ b/libavformat/flvenc.c
@@ -23,6 +23,7 @@
#include "libavutil/dict.h"
#include "libavutil/intfloat.h"
#include "libavutil/avassert.h"
+#include "libavutil/eval.h"
#include "libavutil/mathematics.h"
#include "libavcodec/codec_desc.h"
#include "libavcodec/mpeg4audio.h"
@@ -275,8 +276,10 @@ static void write_metadata(AVFormatContext *s, unsigned
int ts)
AVIOContext *pb = s->pb;
FLVContext *flv = s->priv_data;
int write_duration_filesize = !(flv->flags & FLV_NO_DURATION_FILESIZE);
-int metadata_count = 0;
+int metadata_count = 0, is_num;
int64_t metadata_count_pos;
+double numvalue;
+char *key, *tail;
const AVDictionaryEntry *tag = NULL;
/* write meta_tag */
@@ -378,10 +381,30 @@ static void write_metadata(AVFormatContext *s, unsigned
int ts)
av_log(s, AV_LOG_DEBUG, "Ignoring metadata for %s\n", tag->key);
continue;
}
-put_amf_string(pb, tag->key);
-avio_w8(pb, AMF_DATA_TYPE_STRING);
-put_amf_string(pb, tag->value);
-metadata_count++;
+
+is_num = !strncmp(tag->key, "num_", 4) && *(tag->key + 4);
+key = is_num ? (tag->key + 4) : tag->key;
+
+if (is_num) {
+numvalue = av_strtod(tag->value, &tail);
+if (*tail || numvalue == HUGE_VAL) {
+av_log(s, AV_LOG_ERROR, "Value %s for key %s cannot be stored as a
double-typed number. Will be written as a string\n", tag->value, key);
+key = tag->key;
+is_num = 0;
+}
+}
+
+av_log(s, AV_LOG_DEBUG, "Writing tag %s with value %s count: %d\n", key,
tag->value, metadata_count);
+
+put_amf_string(pb, key);
+if (is_num) {
+put_amf_double(pb, numvalue);
+} else {
+avio_w8(pb, AMF_DATA_TYPE_STRING);
+put_amf_string(pb, tag->value);
+}
+
+metadata_count++;
}
if (write_duration_filesize) {
___
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".
