[FFmpeg-devel] [RFC] Vote STF/SPI 2024-02
Hi all To do the STF/SPI thing properly, and make sure we do what the Community wants. We should do this vote: (unless lots of people reply and say we should skip the vote) (i am also CCing jonatan to make sure the option in the vote actually ask the GA the right question) The vote description will be as follows: The STF/SPI has suggested us to submit an Application / Scope of work before their february meeting. There are about 2 weeks left. The minimum grant is 150 000 € The next STF meeting is expected to be in may. If we submit in february and are not selected we can probably try again in may. Which would increase our chances If we do not submit in february we can probably submit in may. There is no guarantee that money will be available in may, for example between october 2023 and february 2024 no funds where available AFAIK. Wiki page is here: https://trac.ffmpeg.org/wiki/SponsoringPrograms/STF/2024 Option A. The Application and Scope of Work from the WIKI shall be submitted to STF/SPI before the february 2024 meeting, disagreements in it shall be decided by the TC. To achieve continuity, submission shall be done by the same person as previous if possible. Option B. No Application and Scope of Work shall be submitted in february 2024 This is a RFC, so if you see errors in it please suggest changes Thx -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB If you fake or manipulate statistics in a paper in physics you will never get a job again. If you fake or manipulate statistics in a paper in medicin you will get a job for life at the pharma industry. 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] Sovereign Tech Fund
On date Thursday 2024-02-01 00:15:03 +0100, Stefano Sabatini wrote: > José already provided and excellent summary from his side. On my side I meant Jonatas, sorry. ___ 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 3/3] avfilter/yadif_common: fix timestamps with very small timebases
On Wed, Jan 31, 2024 at 03:42:46AM +0100, Marton Balint wrote:
>
>
> On Wed, 31 Jan 2024, Michael Niedermayer wrote:
>
> > On Sun, Jan 28, 2024 at 04:01:36AM +0100, Marton Balint wrote:
> > > Yadif filter assumed that the output timebase is always half of the input
> > > timebase. This is not true if halving the input time base is not
> > > representable
> > > as an AVRational causing the output timestamps to be invalidly scaled in
> > > such a
> > > case.
> > >
> > > So let's use av_reduce instead of av_mul_q when calculating the output
> > > time
> > > base and if the conversion is inexact then let's fall back to the original
> > > timebase which probably makes more parctical sense than using x/INT_MAX.
> > >
> > > Fixes invalidly scaled pts_time values in this command line:
> > > ffmpeg -f lavfi -i testsrc -vf settb=tb=1/20,yadif,showinfo -f
> > > null none
> > >
> > > Signed-off-by: Marton Balint
> > > ---
> > > libavfilter/yadif.h| 2 ++
> > > libavfilter/yadif_common.c | 20 ++--
> > > 2 files changed, 16 insertions(+), 6 deletions(-)
> > >
> > > diff --git a/libavfilter/yadif.h b/libavfilter/yadif.h
> > > index 2c4fed62d2..c144568242 100644
> > > --- a/libavfilter/yadif.h
> > > +++ b/libavfilter/yadif.h
> > > @@ -86,6 +86,8 @@ typedef struct YADIFContext {
> > > * the first field.
> > > */
> > > int current_field; ///< YADIFCurrentField
> > > +
> > > +int pts_divisor;
> > > } YADIFContext;
> > >
> > > void ff_yadif_init_x86(YADIFContext *yadif);
> > > diff --git a/libavfilter/yadif_common.c b/libavfilter/yadif_common.c
> > > index 933372529e..90a5cffc2d 100644
> > > --- a/libavfilter/yadif_common.c
> > > +++ b/libavfilter/yadif_common.c
> > > @@ -61,7 +61,7 @@ FF_ENABLE_DEPRECATION_WARNINGS
> > > int64_t next_pts = yadif->next->pts;
> > >
> > > if (next_pts != AV_NOPTS_VALUE && cur_pts != AV_NOPTS_VALUE) {
> > > -yadif->out->pts = cur_pts + next_pts;
> > > +yadif->out->pts = (cur_pts + next_pts) / yadif->pts_divisor;
> > > } else {
> > > yadif->out->pts = AV_NOPTS_VALUE;
> > > }
> > > @@ -150,8 +150,8 @@ int ff_yadif_filter_frame(AVFilterLink *link, AVFrame
> > > *frame)
> > > ff_ccfifo_inject(&yadif->cc_fifo, yadif->out);
> > > av_frame_free(&yadif->prev);
> > > if (yadif->out->pts != AV_NOPTS_VALUE)
> > > -yadif->out->pts *= 2;
> > > -yadif->out->duration *= 2;
> > > +yadif->out->pts *= 2 / yadif->pts_divisor;
> > > +yadif->out->duration *= 2 / yadif->pts_divisor;
> > > return ff_filter_frame(ctx->outputs[0], yadif->out);
> > > }
> > >
> > > @@ -168,9 +168,9 @@ FF_ENABLE_DEPRECATION_WARNINGS
> > > yadif->out->flags &= ~AV_FRAME_FLAG_INTERLACED;
> > >
> > > if (yadif->out->pts != AV_NOPTS_VALUE)
> > > -yadif->out->pts *= 2;
> > > +yadif->out->pts *= 2 / yadif->pts_divisor;
> > > if (!(yadif->mode & 1))
> > > -yadif->out->duration *= 2;
> > > +yadif->out->duration *= 2 / yadif->pts_divisor;
> >
> > you can use >> instead of division for all above
>
> Even for the first case? Because the right shift would be implementation
> defined for negative timestamps.
we are only supporting twos-complement systems
i thought that was somewhete in teh docs
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Concerning the gods, I have no means of knowing whether they exist or not
or of what sort they may be, because of the obscurity of the subject, and
the brevity of human life -- Protagoras
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 v5] libavformat: add DVD-Video demuxer, powered by libdvdnav and libdvdread
On date Sunday 2024-01-28 16:59:22 -0600, Marth64 wrote:
> - Add option to play only certain chapters or chapter ranges
> - Add option to do a second pass indexing for accurate chapter markers
> - Add documentation
> - Fixes issues with PCM audio
> - Support for essential track dispositions (forced, visual impaired,
> commentary)
> - Better support for structure variances and padding cells/frames
> - More user friendly log messages and errors
> - dvdread/dvdnav logging is relatively very verbose, map lower levels as
> DEBUG logs
>
> Signed-off-by: Marth64
> ---
> Changelog |1 +
> configure |8 +
> doc/demuxers.texi | 129
> libavformat/Makefile |1 +
> libavformat/allformats.c |1 +
> libavformat/dvdvideodec.c | 1409 +
> 6 files changed, 1549 insertions(+)
> create mode 100644 libavformat/dvdvideodec.c
>
> diff --git a/Changelog b/Changelog
> index c1fd66b4bd..9de157abe4 100644
> --- a/Changelog
> +++ b/Changelog
> @@ -23,6 +23,7 @@ version :
> - ffmpeg CLI -bsf option may now be used for input as well as output
> - ffmpeg CLI options may now be used as -/opt , which is equivalent
>to -opt >
> +- DVD-Video demuxer, powered by libdvdnav and libdvdread
>
> version 6.1:
> - libaribcaption decoder
> diff --git a/configure b/configure
> index 21663000f8..d81420992a 100755
> --- a/configure
> +++ b/configure
> @@ -227,6 +227,8 @@ External library support:
>--enable-libdavs2enable AVS2 decoding via libdavs2 [no]
>--enable-libdc1394 enable IIDC-1394 grabbing using libdc1394
> and libraw1394 [no]
> + --enable-libdvdnav enable libdvdnav, needed for DVD demuxing [no]
> + --enable-libdvdread enable libdvdread, needed for DVD demuxing [no]
>--enable-libfdk-aac enable AAC de/encoding via libfdk-aac [no]
>--enable-libfliteenable flite (voice synthesis) support via
> libflite [no]
>--enable-libfontconfig enable libfontconfig, useful for drawtext filter
> [no]
> @@ -1806,6 +1808,8 @@ EXTERNAL_LIBRARY_GPL_LIST="
> frei0r
> libcdio
> libdavs2
> +libdvdnav
> +libdvdread
> librubberband
> libvidstab
> libx264
> @@ -3520,6 +3524,8 @@ dts_demuxer_select="dca_parser"
> dtshd_demuxer_select="dca_parser"
> dv_demuxer_select="dvprofile"
> dv_muxer_select="dvprofile"
> +dvdvideo_demuxer_select="mpegps_demuxer"
> +dvdvideo_demuxer_deps="libdvdnav libdvdread"
> dxa_demuxer_select="riffdec"
> eac3_demuxer_select="ac3_parser"
> evc_demuxer_select="evc_frame_merge_bsf evc_parser"
> @@ -6761,6 +6767,8 @@ enabled libdav1d && require_pkg_config
> libdav1d "dav1d >= 0.5.0" "dav1d
> enabled libdavs2 && require_pkg_config libdavs2 "davs2 >= 1.6.0"
> davs2.h davs2_decoder_open
> enabled libdc1394 && require_pkg_config libdc1394 libdc1394-2
> dc1394/dc1394.h dc1394_new
> enabled libdrm&& check_pkg_config libdrm libdrm xf86drm.h
> drmGetVersion
> +enabled libdvdnav && require_pkg_config libdvdnav "dvdnav >= 6.1.1"
> dvdnav/dvdnav.h dvdnav_open2
> +enabled libdvdread&& require_pkg_config libdvdread "dvdread >=
> 6.1.2" dvdread/dvd_reader.h DVDOpen2 -ldvdread
> enabled libfdk_aac&& { check_pkg_config libfdk_aac fdk-aac
> "fdk-aac/aacenc_lib.h" aacEncOpen ||
> { require libfdk_aac fdk-aac/aacenc_lib.h
> aacEncOpen -lfdk-aac &&
> warn "using libfdk without pkg-config"; } }
> diff --git a/doc/demuxers.texi b/doc/demuxers.texi
> index e4c5b560a6..f7f9e6769a 100644
> --- a/doc/demuxers.texi
> +++ b/doc/demuxers.texi
> @@ -285,6 +285,135 @@ This demuxer accepts the following option:
>
> @end table
>
> +@section dvdvideo
> +
> +DVD-Video demuxer, powered by libdvdnav and libdvdread.
> +
> +Can directly ingest DVD titles, specifically sequential PGCs (see below),
> +into a conversion pipeline. Menus and seeking are not supported at this time.
> +Block devices (DVD drives), ISO files, and directory structures are accepted.
> +Activate with @code{-f dvdvideo} in front of one of these inputs.
> +
> +Underlying playback is fully handled by libdvdnav, and structure parsing by
> libdvdread.
> +Therefore, the ffmpeg build must be configured with these GPL libraries
> enabled.
nit, specifically mention the @code{--enable-libdvdread} and
@code{--enable-libdvdnav} options as done in other places.
> +
> +You will need to provide either the desired "title" number or exact PGC/PG
> coordinates.
> +Many open-source DVD tools and players can aid in providing this information.
> +If not specified, the demuxer will default to title 1 which works for many
> discs.
> +However, due to the flexibility of the DVD standard, it is recommended to
> check manually.
> +There are many discs that are authored strangely or with invalid headers.
> +
> +If the input is a real DVD driv
Re: [FFmpeg-devel] [PATCH] avutil/rational: Document what is to be expected from av_d2q() of doubles representing rational numbers
On Wed, Jan 31, 2024 at 09:30:44PM +0100, epira...@gmail.com wrote:
>
>
> On 31 Jan 2024, at 20:47, Michael Niedermayer wrote:
>
> > Signed-off-by: Michael Niedermayer
> > ---
> > libavutil/rational.h | 4
> > 1 file changed, 4 insertions(+)
> >
> > diff --git a/libavutil/rational.h b/libavutil/rational.h
> > index 8cbfc8e0669..c6ac9fb1d91 100644
> > --- a/libavutil/rational.h
> > +++ b/libavutil/rational.h
> > @@ -168,6 +168,10 @@ static av_always_inline AVRational av_inv_q(AVRational
> > q)
> > * In case of infinity, the returned value is expressed as `{1, 0}` or
> > * `{-1, 0}` depending on the sign.
> > *
> > + * In general rational numbers with |num| <= 1<<26 && |den| <= 1<<26
> > + * can be recovered exactly from their double representation.
> > + * (no exceptions where found within 100M random ones)
>
> I think you meant „were“ here instead of „where“?
fixed
also tested 1B more cases
and 1<<27 as a limit btw fails as is to be expected fro the amount
of bits in the mantisse
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Any man who breaks a law that conscience tells him is unjust and willingly
accepts the penalty by staying in jail in order to arouse the conscience of
the community on the injustice of the law is at that moment expressing the
very highest respect for law. - Martin Luther King Jr
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] fftools/ffmpeg: use correct unit prefix symbol for binary scaled byte values
On date Monday 2024-01-29 15:54:27 +0800, 王昊然 wrote:
> Fix bug #10501
>
> Signed-off-by: WHR
> ---
> fftools/ffmpeg.c | 4 ++--
> fftools/ffmpeg_enc.c | 2 +-
> fftools/ffmpeg_mux.c | 4 ++--
> 3 files changed, 5 insertions(+), 5 deletions(-)
> diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
> index 53df200d1ab..035210a8e90 100644
> --- a/fftools/ffmpeg.c
> +++ b/fftools/ffmpeg.c
> @@ -329,7 +329,7 @@ static void ffmpeg_cleanup(int ret)
>
> if (do_benchmark) {
> int maxrss = getmaxrss() / 1024;
> -av_log(NULL, AV_LOG_INFO, "bench: maxrss=%ikB\n", maxrss);
> +av_log(NULL, AV_LOG_INFO, "bench: maxrss=%iKiB\n", maxrss);
> }
>
> for (i = 0; i < nb_filtergraphs; i++)
> @@ -570,7 +570,7 @@ static void print_report(int is_last_report, int64_t
> timer_start, int64_t cur_ti
> speed = pts != AV_NOPTS_VALUE && t != 0.0 ? (double)pts / AV_TIME_BASE
> / t : -1;
>
> if (total_size < 0) av_bprintf(&buf, "size=N/A time=");
> -elseav_bprintf(&buf, "size=%8.0fkB time=", total_size /
> 1024.0);
> +elseav_bprintf(&buf, "size=%8.0fKiB time=", total_size /
> 1024.0);
> if (pts == AV_NOPTS_VALUE) {
> av_bprintf(&buf, "N/A ");
> } else {
> diff --git a/fftools/ffmpeg_enc.c b/fftools/ffmpeg_enc.c
> index 2a7fba0c51f..bc0d3a334d7 100644
> --- a/fftools/ffmpeg_enc.c
> +++ b/fftools/ffmpeg_enc.c
> @@ -612,7 +612,7 @@ static int update_video_stats(OutputStream *ost, const
> AVPacket *pkt, int write_
>
> bitrate = (pkt->size * 8) / av_q2d(enc->time_base) / 1000.0;
> avg_bitrate = (double)(e->data_size * 8) / ti1 / 1000.0;
> -fprintf(vstats_file, "s_size= %8.0fkB time= %0.3f br= %7.1fkbits/s
> avg_br= %7.1fkbits/s ",
> +fprintf(vstats_file, "s_size= %8.0fKiB time= %0.3f br= %7.1fkbits/s
> avg_br= %7.1fkbits/s ",
> (double)e->data_size / 1024, ti1, bitrate, avg_bitrate);
> fprintf(vstats_file, "type= %c\n", av_get_picture_type_char(pict_type));
>
> diff --git a/fftools/ffmpeg_mux.c b/fftools/ffmpeg_mux.c
> index ab86abee14f..ee708267c1e 100644
> --- a/fftools/ffmpeg_mux.c
> +++ b/fftools/ffmpeg_mux.c
> @@ -725,8 +725,8 @@ static void mux_final_stats(Muxer *mux)
> }
>
> av_log(of, AV_LOG_INFO,
> - "video:%1.0fkB audio:%1.0fkB subtitle:%1.0fkB other
> streams:%1.0fkB "
> - "global headers:%1.0fkB muxing overhead: %s\n",
> + "video:%1.0fKiB audio:%1.0fKiB subtitle:%1.0fKiB other
> streams:%1.0fKiB "
> + "global headers:%1.0fKiB muxing overhead: %s\n",
> video_size/ 1024.0,
> audio_size/ 1024.0,
> subtitle_size / 1024.0,
LGTM, I'll apply in a few days if I see no comments, thanks.
___
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] Sovereign Tech Fund
On date Wednesday 2024-01-31 18:10:57 +0200, Rémi Denis-Courmont wrote: > Hi, [...] > Sarcasm aside, I take that to mean that SPI has been involved with those > discussions for months in a private and closed process. Michael asserted that > an open inclusive process is better than the usual closed approach whence the > funding goes through a company. > > It looks to me that those SPI discussions were just as opaque and closed, and > all the talk of openess is just pretense. It does not help that Michael, and > now you too, misrepresent any challenge to SPI proposed *process* as an > attempt to reject the idea of STF sponsorship, under the convenient pretext > that there is not enough time. > > This is further aggravated by the context that Michael brought forward the > idea of funding developers through SPI 3 months ago (in actual Earth units). > From your statement, I have to infer that Thilo, Michael and SPI already knew > of the STF plan and concealed that key piece of contextual information back > then. > José already provided and excellent summary from his side. On my side I can say I was involved in the discussion, and that this was mostly about the feasibility and the groundwork of approaching STF and later SPI. So in my opinion there was no need to involve the community at that early stage, especially given that until the past week there was still no evidence that STF was providing a grant (and BTW, still this needs to be substantiated with a SOW and then it will have to be reviewed and approved on the STF side). Also SPI was involved at a later stage, after the investigation about using the donors fund for active development (which also involves the handling of SOW from SPI to the individual contributor). The main result of that investigation was discussed in the open and can be found here: https://ffmpeg.org/pipermail/ffmpeg-devel/2023-October/315702.html If I undestand it correctly, it was never committed because there was a disagreement about where to put it (ffmpeg or ffmpeg-web) and about the general intent, then at some point the discussion died off before a conclusion was really reached. Note that the focus in that case was to make good use of the donations fund (keeping it in the account is not a good use for it). > In hindsight, it feels hypocritical to me that they were arguing for the SPI > path, and against the corporate path, on the basis of openess already then, > to > be honest. > > I can only agree with Anton that this looks like an attempt to strongarm the > community. This is ostensibly being to ignore all the objections that were > already brought in October and are being brought again now, with the > complicity of SPI. I can't say that this looks well on SPI, but that's just > my > personal opinion. SPI was involved at a later stage to act as fiscal sponsor for STF. Just to reiterate, SPI involvement was requested, and was not actively seeked by SPI itself. I cannot read any attempt to strongarm the community, nor I see why this should challenge the corporate path (which has a different focus and has its own merits). > With all that said, I don't think anybody will attempt to prevent this from > happening (if they even can?). But that will take place without the consent > of > the GA, without any legitimacy on the claims of openess and inclusiveness, > and > obviously without any form of preclearance from the technical appropriateness > of the resulting code contributions. It's unfortunate there is a tight deadline - one option would be to try to delay the deadline and ask General Assembly for a vote before the application is sent - we might probably want both things to avoid the feeling that this is done against the "community" and create a tense environment, but any of this might probably result in voiding the opportunity. Also, it should be assumed that this proposal was done in good faith, in view of the sustainability discussions done in the past months. ___ 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] Sovereign Tech Fund
On Wed, Jan 31, 2024 at 09:55:00PM +, Kieran Kunhya wrote: > On Wed, 31 Jan 2024 at 21:45, Derek Buitenhuis > wrote: > > > On 1/30/2024 1:48 AM, Michael Niedermayer wrote: > > > https://trac.ffmpeg.org/wiki/SponsoringPrograms/STF/2024 > > > > Not to derail this fine thread, but what forks does the Merge Forks > > project refer to? > > > > - Derek > > > > I also added a note that 70 USD for coverity is way too much. I picked a > random issue 1503073 and within a minute saw that it was a false positive. > I don't deserve 70USD for that. you forgot to add yourself with a lower price its weak to claim something expensive (which is true) but not willing to do the work at a lower price about antons comment "Objections: (Anton) Coverity (and other static analysis tools) are notoriously prone to false positives. I am concerned that this might lead to a large number of patches that "fix" such false positives, but make the code worse." It was me years ago who brought the number of coverity issues down to a small number. It has exploded since. anton, where does this misstrust come from ? When i did all that fixing of covertiy issues long ago i closed many i think about 1/3 where real issues IIRC 2/3 where false positves or "intended" i closed the false positives and marked them accordingly as false or intended or whatever was correct. Why should i suddenly do something different ? I did it for 100% free back then and here it wouldnt even make sense, closing false positives also counts as resolved. Its less work even to get 70USD ;) and about the 70 USD. Its a point at which i hoped someone else would add himself, apparently its enough someone complains but noone wants to do it still. hmm and about 1min, the average time it takes to analyze issues is definitly going to be above this unless the issues look very different than previosuly though also you will surely find a dozen similar ones where you can close each in 5sec. on average 30min per issues with all analysis, double checking documentation 1/3 of the time writing a patch, testing and submitting is more real. So you could make 140USD per hour IMHO at 70USD per issue I think thats realistic unless the issues are different now than years ago (the 30min estimate includes a saftey factor which one has to include for this kind of work) thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Modern terrorism, a quick summary: Need oil, start war with country that has oil, kill hundread thousand in war. Let country fall into chaos, be surprised about raise of fundamantalists. Drop more bombs, kill more people, be surprised about them taking revenge and drop even more bombs and strip your own citizens of their rights and freedoms. to be continued 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".
[FFmpeg-devel] [PATCH v2 4/5] avutil/channel_layout: add av_channel_layout_retype()
v2: add conversion from custom layout to ambisonic
Signed-off-by: Marton Balint
---
doc/APIchanges | 3 ++
libavutil/channel_layout.c | 74 ++
libavutil/channel_layout.h | 11 ++
libavutil/version.h| 2 +-
4 files changed, 89 insertions(+), 1 deletion(-)
diff --git a/doc/APIchanges b/doc/APIchanges
index 8e8498f803..ce1e816fa5 100644
--- a/doc/APIchanges
+++ b/doc/APIchanges
@@ -2,6 +2,9 @@ The last version increases of all libraries were on 2023-02-09
API changes, most recent first:
+2024-02-xx - xx - lavu 58.38.100 - channel_layout.h
+ Add av_channel_layout_retype().
+
2024-02-xx - xx - lavu 58.37.100 - channel_layout.h
Add av_channel_layout_from_custom().
diff --git a/libavutil/channel_layout.c b/libavutil/channel_layout.c
index 0810d32bf6..056b7f7c10 100644
--- a/libavutil/channel_layout.c
+++ b/libavutil/channel_layout.c
@@ -1036,3 +1036,77 @@ uint64_t av_channel_layout_subset(const AVChannelLayout
*channel_layout,
return ret;
}
+
+static int64_t masked_description(AVChannelLayout *channel_layout, int
start_channel)
+{
+uint64_t mask = 0;
+for (int i = start_channel; i < channel_layout->nb_channels; i++) {
+enum AVChannel ch = channel_layout->u.map[i].id;
+if (ch >= 0 && ch < 63 && mask < (1ULL << ch))
+mask |= (1ULL << ch);
+else
+return AVERROR(EINVAL);
+}
+return mask;
+}
+
+int av_channel_layout_retype(AVChannelLayout *channel_layout, enum
AVChannelOrder order)
+{
+if (!av_channel_layout_check(channel_layout))
+return AVERROR(EINVAL);
+
+if (channel_layout->order == order)
+return 0;
+
+switch (order) {
+case AV_CHANNEL_ORDER_UNSPEC: {
+int nb_channels = channel_layout->nb_channels;
+av_channel_layout_uninit(channel_layout);
+channel_layout->order = AV_CHANNEL_ORDER_UNSPEC;
+channel_layout->nb_channels = nb_channels;
+return 0;
+}
+case AV_CHANNEL_ORDER_CUSTOM: {
+AVChannelLayout custom = { 0 };
+int ret = av_channel_layout_from_custom(&custom,
channel_layout->nb_channels);
+if (ret < 0)
+return ret;
+if (channel_layout->order != AV_CHANNEL_ORDER_UNSPEC)
+for (int i = 0; i < channel_layout->nb_channels; i++)
+custom.u.map[i].id =
av_channel_layout_channel_from_index(channel_layout, i);
+av_channel_layout_uninit(channel_layout);
+*channel_layout = custom;
+return 0;
+}
+case AV_CHANNEL_ORDER_NATIVE:
+if (channel_layout->order == AV_CHANNEL_ORDER_CUSTOM) {
+int64_t mask = masked_description(channel_layout, 0);
+if (mask < 0)
+return 1;
+av_channel_layout_uninit(channel_layout);
+return av_channel_layout_from_mask(channel_layout, mask);
+} else {
+return 1;
+}
+case AV_CHANNEL_ORDER_AMBISONIC:
+if (channel_layout->order == AV_CHANNEL_ORDER_CUSTOM) {
+int64_t mask;
+int nb_channels = channel_layout->nb_channels;
+int order = ambisonic_order(channel_layout);
+if (order < 0)
+return 1;
+mask = masked_description(channel_layout, (order + 1) * (order +
1));
+if (mask < 0)
+return 1;
+av_channel_layout_uninit(channel_layout);
+channel_layout->order = AV_CHANNEL_ORDER_AMBISONIC;
+channel_layout->nb_channels = nb_channels;
+channel_layout->u.mask = mask;
+return 0;
+} else {
+return 1;
+}
+default:
+return 1;
+}
+}
diff --git a/libavutil/channel_layout.h b/libavutil/channel_layout.h
index 37629ab5d2..7e27a00d39 100644
--- a/libavutil/channel_layout.h
+++ b/libavutil/channel_layout.h
@@ -817,6 +817,17 @@ int av_channel_layout_check(const AVChannelLayout
*channel_layout);
*/
int av_channel_layout_compare(const AVChannelLayout *chl, const
AVChannelLayout *chl1);
+/**
+ * Try changing the AVChannelOrder of a channel layout.
+ *
+ * @param channel_layout channel layout which will be changed
+ * @param order the desired channel layout order
+ * @return 0 on success or if the channel layout is already in the desired
order
+ * 1 if using the desired order is not possible for the specified
layout
+ * AVERROR code on error
+ */
+int av_channel_layout_retype(AVChannelLayout *channel_layout, enum
AVChannelOrder order);
+
/**
* @}
*/
diff --git a/libavutil/version.h b/libavutil/version.h
index 3b38f8f5da..cebf4a0acd 100644
--- a/libavutil/version.h
+++ b/libavutil/version.h
@@ -79,7 +79,7 @@
*/
#define LIBAVUTIL_VERSION_MAJOR 58
-#define LIBAVUTIL_VERSION_MINOR 37
+#define LIBAVUTIL_VERSION_MINOR 38
#define LIBAVUTIL_VERSION_MICRO 100
#define LIBAVUTIL_VERSION_INT AV_VERSION_INT(LIBAVUTIL_
[FFmpeg-devel] [PATCH v2 3/3] avfilter/yadif_common: fix timestamps with very small timebases
Yadif filter assumed that the output timebase is always half of the input
timebase. This is not true if halving the input time base is not representable
as an AVRational causing the output timestamps to be invalidly scaled in such a
case.
So let's use av_reduce instead of av_mul_q when calculating the output time
base and if the conversion is inexact then let's fall back to the original
timebase which probably makes more parctical sense than using x/INT_MAX.
Fixes invalidly scaled pts_time values in this command line:
ffmpeg -f lavfi -i testsrc -vf settb=tb=1/20,yadif,showinfo -f null none
v2: use less divisons and fix durations
Signed-off-by: Marton Balint
---
libavfilter/yadif.h| 2 ++
libavfilter/yadif_common.c | 24 +++-
2 files changed, 21 insertions(+), 5 deletions(-)
diff --git a/libavfilter/yadif.h b/libavfilter/yadif.h
index 2c4fed62d2..888ba12365 100644
--- a/libavfilter/yadif.h
+++ b/libavfilter/yadif.h
@@ -86,6 +86,8 @@ typedef struct YADIFContext {
* the first field.
*/
int current_field; ///< YADIFCurrentField
+
+int pts_multiplier;
} YADIFContext;
void ff_yadif_init_x86(YADIFContext *yadif);
diff --git a/libavfilter/yadif_common.c b/libavfilter/yadif_common.c
index 933372529e..446ffb7c3d 100644
--- a/libavfilter/yadif_common.c
+++ b/libavfilter/yadif_common.c
@@ -62,6 +62,10 @@ FF_ENABLE_DEPRECATION_WARNINGS
if (next_pts != AV_NOPTS_VALUE && cur_pts != AV_NOPTS_VALUE) {
yadif->out->pts = cur_pts + next_pts;
+if (yadif->pts_multiplier == 1) {
+yadif->out->pts /= 2;
+yadif->out->duration /= 2;
+}
} else {
yadif->out->pts = AV_NOPTS_VALUE;
}
@@ -150,8 +154,8 @@ int ff_yadif_filter_frame(AVFilterLink *link, AVFrame
*frame)
ff_ccfifo_inject(&yadif->cc_fifo, yadif->out);
av_frame_free(&yadif->prev);
if (yadif->out->pts != AV_NOPTS_VALUE)
-yadif->out->pts *= 2;
-yadif->out->duration *= 2;
+yadif->out->pts *= yadif->pts_multiplier;
+yadif->out->duration *= yadif->pts_multiplier;
return ff_filter_frame(ctx->outputs[0], yadif->out);
}
@@ -168,9 +172,11 @@ FF_ENABLE_DEPRECATION_WARNINGS
yadif->out->flags &= ~AV_FRAME_FLAG_INTERLACED;
if (yadif->out->pts != AV_NOPTS_VALUE)
-yadif->out->pts *= 2;
+yadif->out->pts *= yadif->pts_multiplier;
if (!(yadif->mode & 1))
-yadif->out->duration *= 2;
+yadif->out->duration *= yadif->pts_multiplier;
+else if (yadif->pts_multiplier == 1)
+yadif->out->duration /= 2;
return return_frame(ctx, 0);
}
@@ -213,9 +219,17 @@ int ff_yadif_config_output_common(AVFilterLink *outlink)
{
AVFilterContext *ctx = outlink->src;
YADIFContext *yadif = ctx->priv;
+AVRational tb = ctx->inputs[0]->time_base;
int ret;
-outlink->time_base = av_mul_q(ctx->inputs[0]->time_base, (AVRational){1,
2});
+if (av_reduce(&outlink->time_base.num, &outlink->time_base.den, tb.num,
tb.den * 2LL, INT_MAX)) {
+yadif->pts_multiplier = 2;
+} else {
+av_log(ctx, AV_LOG_WARNING, "Cannot use exact output timebase\n");
+outlink->time_base = tb;
+yadif->pts_multiplier = 1;
+}
+
outlink->w = ctx->inputs[0]->w;
outlink->h = ctx->inputs[0]->h;
--
2.35.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] Sovereign Tech Fund
On Wed, 31 Jan 2024, 22:40 Michael Niedermayer, wrote: > On Wed, Jan 31, 2024 at 09:54:05PM +, Kieran Kunhya wrote: > > On Wed, 31 Jan 2024 at 21:43, Michael Niedermayer < > mich...@niedermayer.cc> > > wrote: > > > > > On Wed, Jan 31, 2024 at 08:19:04PM +, Kieran Kunhya wrote: > > > > On Wed, 31 Jan 2024 at 19:17, Cosmin Stejerean via ffmpeg-devel < > > > > ffmpeg-devel@ffmpeg.org> wrote: > > > [...] > > > > > This is most likely referring to the email from Thilo that an > anonymous > > > > > corporate sponsor is providing ffmpeg with a booth at NAB 2024 > > > > > > > > > > > https://www.mail-archive.com/ffmpeg-devel@ffmpeg.org/msg154158.html > > > > > > > > > > Seems off-topic for this thread about SPI and STF. > > > > > > > > > > - Cosmin > > > > > > > > > > > > > It's really not off-topic. It's about agreements that are made on > behalf > > > of > > > > the project without consulting the community, which is what appears > to be > > > [...] > > > > We love transparency in this project, right? > > > > > > Yes, i cant awnser your questions but i have some questions myself > after > > > looking for NAB related things > > > > > > who did the 2023 booth on NAB for FFmpeg (W3323) ? > > > here: > > > > > > > https://www.linkedin.com/posts/videolan_nabshow-activity-7054494677881769985-ZCK7/ > > > We can clearly see FFmpeg logo and FFmpeg text in this > > > > > > Also in the reactions, i dont recognize any except you. > > > > > > and where was that discussed with the FFmpeg community? > > > > > > Iam reading there where no FFmpeg developers on that booth just > buissness > > > people > > > from someone who vissited, so iam a bit confused. > > > > > > > Thilo was on the booth (when he felt like showing up) and j-b was on the > > booth along with other Videolabs people. > > Julien Navas, myself and other Videolabs people built the booth in our > own > > time free of charge. > > > > I have no idea who the " buissness people" you talk about are. > > Where did you discuss the creation of this Booth with the FFmpeg community > ? > > thx > Ask the people who paid for it and staffed it. 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] Sovereign Tech Fund
On Wed, Jan 31, 2024 at 09:54:05PM +, Kieran Kunhya wrote: > On Wed, 31 Jan 2024 at 21:43, Michael Niedermayer > wrote: > > > On Wed, Jan 31, 2024 at 08:19:04PM +, Kieran Kunhya wrote: > > > On Wed, 31 Jan 2024 at 19:17, Cosmin Stejerean via ffmpeg-devel < > > > ffmpeg-devel@ffmpeg.org> wrote: > > [...] > > > > This is most likely referring to the email from Thilo that an anonymous > > > > corporate sponsor is providing ffmpeg with a booth at NAB 2024 > > > > > > > > https://www.mail-archive.com/ffmpeg-devel@ffmpeg.org/msg154158.html > > > > > > > > Seems off-topic for this thread about SPI and STF. > > > > > > > > - Cosmin > > > > > > > > > > It's really not off-topic. It's about agreements that are made on behalf > > of > > > the project without consulting the community, which is what appears to be > > [...] > > > We love transparency in this project, right? > > > > Yes, i cant awnser your questions but i have some questions myself after > > looking for NAB related things > > > > who did the 2023 booth on NAB for FFmpeg (W3323) ? > > here: > > > > https://www.linkedin.com/posts/videolan_nabshow-activity-7054494677881769985-ZCK7/ > > We can clearly see FFmpeg logo and FFmpeg text in this > > > > Also in the reactions, i dont recognize any except you. > > > > and where was that discussed with the FFmpeg community? > > > > Iam reading there where no FFmpeg developers on that booth just buissness > > people > > from someone who vissited, so iam a bit confused. > > > > Thilo was on the booth (when he felt like showing up) and j-b was on the > booth along with other Videolabs people. > Julien Navas, myself and other Videolabs people built the booth in our own > time free of charge. > > I have no idea who the " buissness people" you talk about are. Where did you discuss the creation of this Booth with the FFmpeg community ? thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Dictatorship naturally arises out of democracy, and the most aggravated form of tyranny and slavery out of the most extreme liberty. -- Plato 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] Sovereign Tech Fund
On Wed, 31 Jan 2024 at 21:45, Derek Buitenhuis wrote: > On 1/30/2024 1:48 AM, Michael Niedermayer wrote: > > https://trac.ffmpeg.org/wiki/SponsoringPrograms/STF/2024 > > Not to derail this fine thread, but what forks does the Merge Forks > project refer to? > > - Derek > I also added a note that 70 USD for coverity is way too much. I picked a random issue 1503073 and within a minute saw that it was a false positive. I don't deserve 70USD for that. 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] Sovereign Tech Fund
On Wed, 31 Jan 2024 at 21:43, Michael Niedermayer wrote: > On Wed, Jan 31, 2024 at 08:19:04PM +, Kieran Kunhya wrote: > > On Wed, 31 Jan 2024 at 19:17, Cosmin Stejerean via ffmpeg-devel < > > ffmpeg-devel@ffmpeg.org> wrote: > [...] > > > This is most likely referring to the email from Thilo that an anonymous > > > corporate sponsor is providing ffmpeg with a booth at NAB 2024 > > > > > > https://www.mail-archive.com/ffmpeg-devel@ffmpeg.org/msg154158.html > > > > > > Seems off-topic for this thread about SPI and STF. > > > > > > - Cosmin > > > > > > > It's really not off-topic. It's about agreements that are made on behalf > of > > the project without consulting the community, which is what appears to be > [...] > > We love transparency in this project, right? > > Yes, i cant awnser your questions but i have some questions myself after > looking for NAB related things > > who did the 2023 booth on NAB for FFmpeg (W3323) ? > here: > > https://www.linkedin.com/posts/videolan_nabshow-activity-7054494677881769985-ZCK7/ > We can clearly see FFmpeg logo and FFmpeg text in this > > Also in the reactions, i dont recognize any except you. > > and where was that discussed with the FFmpeg community? > > Iam reading there where no FFmpeg developers on that booth just buissness > people > from someone who vissited, so iam a bit confused. > Thilo was on the booth (when he felt like showing up) and j-b was on the booth along with other Videolabs people. Julien Navas, myself and other Videolabs people built the booth in our own time free of charge. I have no idea who the " buissness people" you talk about are. 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] Sovereign Tech Fund
On 1/30/2024 1:48 AM, Michael Niedermayer wrote: > https://trac.ffmpeg.org/wiki/SponsoringPrograms/STF/2024 Not to derail this fine thread, but what forks does the Merge Forks project refer to? - Derek ___ 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] Sovereign Tech Fund
On Wed, Jan 31, 2024 at 08:19:04PM +, Kieran Kunhya wrote: > On Wed, 31 Jan 2024 at 19:17, Cosmin Stejerean via ffmpeg-devel < > ffmpeg-devel@ffmpeg.org> wrote: [...] > > This is most likely referring to the email from Thilo that an anonymous > > corporate sponsor is providing ffmpeg with a booth at NAB 2024 > > > > https://www.mail-archive.com/ffmpeg-devel@ffmpeg.org/msg154158.html > > > > Seems off-topic for this thread about SPI and STF. > > > > - Cosmin > > > > It's really not off-topic. It's about agreements that are made on behalf of > the project without consulting the community, which is what appears to be [...] > We love transparency in this project, right? Yes, i cant awnser your questions but i have some questions myself after looking for NAB related things who did the 2023 booth on NAB for FFmpeg (W3323) ? here: https://www.linkedin.com/posts/videolan_nabshow-activity-7054494677881769985-ZCK7/ We can clearly see FFmpeg logo and FFmpeg text in this Also in the reactions, i dont recognize any except you. and where was that discussed with the FFmpeg community? Iam reading there where no FFmpeg developers on that booth just buissness people from someone who vissited, so iam a bit confused. thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB If you drop bombs on a foreign country and kill a hundred thousand innocent people, expect your government to call the consequence "unprovoked inhuman terrorist attacks" and use it to justify dropping more bombs and killing more people. The technology changed, the idea is old. 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] Sovereign Tech Fund
On date Wednesday 2024-01-31 13:30:50 +0100, Anton Khirnov wrote: > Quoting Stefano Sabatini (2024-01-30 00:53:25) > > On date Monday 2024-01-29 22:11:49 +0100, Anton Khirnov wrote: [...] > > > 1) How does the project protect itself from pre-approving some code that > > >does not exist yet? This is not just some theoretical danger, it's > > >easily possible that some project sounds good in theory, but actually > > >implementing it comes with so many gotchas and caveats that it ends > > >up being not worth it. Or there are fundamental technical > > >disagreements about the specific way it's been implemented. Both > > >cases exist in our history. > > > > The design and investigative work should be covered as part of the > > SOW. In other words, the SOW should also cover the preliminary design > > and experimentation. In case it leads to no committable work (which is > > unlikely but not impossible), the output should be a document/report > > documenting the result of the initial investigation, and the project > > might be aborted at that point. > > > > This should protect both the developer and the project. In each case > > it should be assumed that the final result of the investigation would > > not lead to committable deliverables, but to design documents which > > might lay the foundation of further work (possibly in a different > > direction). > > That might be a viable direction, but it does not really solve the > problem. Initial investigation only gets you so far and some issues > simply do not become apparent until quite far in the development > process. > > E.g. my recent threading work (that keeps getting mentioned in this > thread as an example of what a cleanup project could look like) was > largely composed of many "sub-projects", each disentangling a specific > feature or area. And there was no reliable way to predict in advance > whether a given sub-project would take two hours or two weeks. So let's tweak the format. It might be formulated as something as: --8< This project covers doing this and that. It will be split in several stages lasting a given amount of time (e.g. two months per each stage). At the end of each stage the developer will provide a report giving an overview of the findings and of delivered code, which will be the subject of the invoice. --8< In this way we drop the requirement on achieving a specific goal in terms of committed code, and require instead a report to document the changes/finding (which will be subject to validation). Maybe José can provide some guidance about the viability of this specific format. Assuming this format is acceptable on the STF/SPI side, the next problem is to understand who is going to provide the validation based on the report. The SPI liaison might be involved but only to sign-off, not to provide the actual validation, which must be agreed upon by the project according to some agreed internal procedures. Other issues might arise in case the work is delayed due to various circumstances (e.g. the developer getting sick or having other external impediments or having more urgent tasks to attend). In this case I can foresee a few possible outcomes: the developer will delay sending the invoice, or the invoiced sum is reduced accordingly. It seems to me we need to design these validation processes in advance or we risk to turn each invoice delivery into a potential flamefest. ___ 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] avutil/rational: Document what is to be expected from av_d2q() of doubles representing rational numbers
On 31 Jan 2024, at 20:47, Michael Niedermayer wrote:
> Signed-off-by: Michael Niedermayer
> ---
> libavutil/rational.h | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/libavutil/rational.h b/libavutil/rational.h
> index 8cbfc8e0669..c6ac9fb1d91 100644
> --- a/libavutil/rational.h
> +++ b/libavutil/rational.h
> @@ -168,6 +168,10 @@ static av_always_inline AVRational av_inv_q(AVRational q)
> * In case of infinity, the returned value is expressed as `{1, 0}` or
> * `{-1, 0}` depending on the sign.
> *
> + * In general rational numbers with |num| <= 1<<26 && |den| <= 1<<26
> + * can be recovered exactly from their double representation.
> + * (no exceptions where found within 100M random ones)
I think you meant „were“ here instead of „where“?
> + *
> * @param d `double` to convert
> * @param max Maximum allowed numerator and denominator
> * @return `d` in AVRational form
> --
> 2.17.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 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] Sovereign Tech Fund
On Wed, 31 Jan 2024 at 19:17, Cosmin Stejerean via ffmpeg-devel < ffmpeg-devel@ffmpeg.org> wrote: > > > > On Jan 31, 2024, at 11:07 AM, Michael Niedermayer < > mich...@niedermayer.cc> wrote: > > > > On Wed, Jan 31, 2024 at 06:22:41PM +, Kieran Kunhya wrote: > >> On Wed, 31 Jan 2024 at 18:03, Michael Niedermayer < > mich...@niedermayer.cc> > >> wrote: > >> > >>> Hi Jonatas, Remi > >>> > >>> _THIS_ reply shows why i LOVE SPI > >>> > >>> I mean this is transparency, anyone try to get something similar from a > >>> corporation > >>> > >>> Just in the last 48h i have seen a reminder from a CEO about > "shareholder > >>> agreement" > >>> and privacy > >>> > >> > >> If you want transparency, where is the agreement between SPI and STF? > > > >> Where > >> is the agreement for the NAB booth? > > > > I did search my inbox and spam folder fro NAB but nothing looked related > to a booth agreement. > > I have someoen trying to sell me an "Attendees Database" for NAB since > 2018 though > > and lots of can nab is spam. > > > > So either i searched for the wrong term or i was not CC-ed on such an > agreement > > > > This is most likely referring to the email from Thilo that an anonymous > corporate sponsor is providing ffmpeg with a booth at NAB 2024 > > https://www.mail-archive.com/ffmpeg-devel@ffmpeg.org/msg154158.html > > Seems off-topic for this thread about SPI and STF. > > - Cosmin > It's really not off-topic. It's about agreements that are made on behalf of the project without consulting the community, which is what appears to be happening between SPI and STF as well. There is currently a booth registered under the FFmpeg name: https://nab24.mapyourshow.com/8_0/exhview/?hallID=W&selectedBooth=W4232 Currently it has the following address associated to FFmpeg: Bergemannweg 20 Berlin 13503 Germany Who does this address belong to? Who will be paying the construction costs, graphics, furniture costs, etc for this booth? Who will be staffing the booth? Derek and I have asked this question several times now and received no response. We love transparency in this project, right? Regards, Kieran Kunhya Sent from my mobile device ___ 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/rational: Document what is to be expected from av_d2q() of doubles representing rational numbers
Signed-off-by: Michael Niedermayer
---
libavutil/rational.h | 4
1 file changed, 4 insertions(+)
diff --git a/libavutil/rational.h b/libavutil/rational.h
index 8cbfc8e0669..c6ac9fb1d91 100644
--- a/libavutil/rational.h
+++ b/libavutil/rational.h
@@ -168,6 +168,10 @@ static av_always_inline AVRational av_inv_q(AVRational q)
* In case of infinity, the returned value is expressed as `{1, 0}` or
* `{-1, 0}` depending on the sign.
*
+ * In general rational numbers with |num| <= 1<<26 && |den| <= 1<<26
+ * can be recovered exactly from their double representation.
+ * (no exceptions where found within 100M random ones)
+ *
* @param d `double` to convert
* @param max Maximum allowed numerator and denominator
* @return `d` in AVRational form
--
2.17.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] avcodec/tiff: pass arguments to bytestream2_seek in the right order
The function signature for bytestream2_seek is (gb, offset, whence); Before this patch, the code passed (gb, SEEK_SET, offset), which is incorrect. Siged-off-by: Leo Izen --- libavcodec/tiff.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libavcodec/tiff.c b/libavcodec/tiff.c index adb49e4525..3ce441aa2c 100644 --- a/libavcodec/tiff.c +++ b/libavcodec/tiff.c @@ -1701,7 +1701,7 @@ static int tiff_decode_tag(TiffContext *s, AVFrame *frame) break; case TIFF_ICC_PROFILE: gb_temp = s->gb; -bytestream2_seek(&gb_temp, SEEK_SET, off); +bytestream2_seek(&gb_temp, off, SEEK_SET); if (bytestream2_get_bytes_left(&gb_temp) < count) return AVERROR_INVALIDDATA; -- 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".
Re: [FFmpeg-devel] Sovereign Tech Fund
I can't find anything in SPI related to NAB either. I can ask the officers if they're aware of something from NAB, but I don't think that would be the case. I can find some old booths for FOSSEM, FOSDEM and whatnot though. Can you double check? (Also: What's the relation between NAB and this sponsorship?) Regards, Jonatas L. Nogueira (“Jesusalva”) SPI Board of Directors On Wed, Jan 31, 2024, 16:07 Michael Niedermayer wrote: > On Wed, Jan 31, 2024 at 06:22:41PM +, Kieran Kunhya wrote: > > On Wed, 31 Jan 2024 at 18:03, Michael Niedermayer < > mich...@niedermayer.cc> > > wrote: > > > > > Hi Jonatas, Remi > > > > > > _THIS_ reply shows why i LOVE SPI > > > > > > I mean this is transparency, anyone try to get something similar from a > > > corporation > > > > > > Just in the last 48h i have seen a reminder from a CEO about > "shareholder > > > agreement" > > > and privacy > > > > > > > If you want transparency, where is the agreement between SPI and STF? > > > Where > > is the agreement for the NAB booth? > > I did search my inbox and spam folder fro NAB but nothing looked related > to a booth agreement. > I have someoen trying to sell me an "Attendees Database" for NAB since > 2018 though > and lots of can nab is spam. > > So either i searched for the wrong term or i was not CC-ed on such an > agreement > > thx > > [...] > > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > The educated differ from the uneducated as much as the living from the > dead. -- Aristotle > ___ 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] Sovereign Tech Fund
> On Jan 31, 2024, at 11:07 AM, Michael Niedermayer > wrote: > > On Wed, Jan 31, 2024 at 06:22:41PM +, Kieran Kunhya wrote: >> On Wed, 31 Jan 2024 at 18:03, Michael Niedermayer >> wrote: >> >>> Hi Jonatas, Remi >>> >>> _THIS_ reply shows why i LOVE SPI >>> >>> I mean this is transparency, anyone try to get something similar from a >>> corporation >>> >>> Just in the last 48h i have seen a reminder from a CEO about "shareholder >>> agreement" >>> and privacy >>> >> >> If you want transparency, where is the agreement between SPI and STF? > >> Where >> is the agreement for the NAB booth? > > I did search my inbox and spam folder fro NAB but nothing looked related to a > booth agreement. > I have someoen trying to sell me an "Attendees Database" for NAB since 2018 > though > and lots of can nab is spam. > > So either i searched for the wrong term or i was not CC-ed on such an > agreement > This is most likely referring to the email from Thilo that an anonymous corporate sponsor is providing ffmpeg with a booth at NAB 2024 https://www.mail-archive.com/ffmpeg-devel@ffmpeg.org/msg154158.html Seems off-topic for this thread about SPI and STF. - Cosmin ___ 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] Sovereign Tech Fund
On Wed, Jan 31, 2024 at 06:22:41PM +, Kieran Kunhya wrote: > On Wed, 31 Jan 2024 at 18:03, Michael Niedermayer > wrote: > > > Hi Jonatas, Remi > > > > _THIS_ reply shows why i LOVE SPI > > > > I mean this is transparency, anyone try to get something similar from a > > corporation > > > > Just in the last 48h i have seen a reminder from a CEO about "shareholder > > agreement" > > and privacy > > > > If you want transparency, where is the agreement between SPI and STF? > Where > is the agreement for the NAB booth? I did search my inbox and spam folder fro NAB but nothing looked related to a booth agreement. I have someoen trying to sell me an "Attendees Database" for NAB since 2018 though and lots of can nab is spam. So either i searched for the wrong term or i was not CC-ed on such an agreement thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The educated differ from the uneducated as much as the living from the dead. -- Aristotle 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] Sovereign Tech Fund
On Wed, 31 Jan 2024 at 18:40, Jonatas L. Nogueira wrote: > I assume you don't mean National Association of Broadcasters by "NAB", so > I would need to know what booth you're talking about. > That is what I mean. Kieran > On Wed, Jan 31, 2024 at 3:22 PM Kieran Kunhya wrote: > >> >> >> On Wed, 31 Jan 2024 at 18:03, Michael Niedermayer >> wrote: >> >>> Hi Jonatas, Remi >>> >>> _THIS_ reply shows why i LOVE SPI >>> >>> I mean this is transparency, anyone try to get something similar from a >>> corporation >>> >>> Just in the last 48h i have seen a reminder from a CEO about >>> "shareholder agreement" >>> and privacy >>> >> >> If you want transparency, where is the agreement between SPI and STF? >> Where is the agreement for the NAB booth? >> >> 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] Sovereign Tech Fund
There are no agreements between SPI and STF as of 31st January 2024. However, if you submit a Scope of Work, then an agreement will be made if STF approves the sponsorship (on the Feb 14th or later). I assume you don't mean National Association of Broadcasters by "NAB", so I would need to know what booth you're talking about. -- Jonatas L. Nogueira (“jesusalva”) Board of Directors Member Software in the Public Interest, Inc. On Wed, Jan 31, 2024 at 3:22 PM Kieran Kunhya wrote: > > > On Wed, 31 Jan 2024 at 18:03, Michael Niedermayer > wrote: > >> Hi Jonatas, Remi >> >> _THIS_ reply shows why i LOVE SPI >> >> I mean this is transparency, anyone try to get something similar from a >> corporation >> >> Just in the last 48h i have seen a reminder from a CEO about "shareholder >> agreement" >> and privacy >> > > If you want transparency, where is the agreement between SPI and STF? > Where is the agreement for the NAB booth? > > 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/4 v6] avformat: add a Tile Grid stream group type
On 1/31/2024 3:33 PM, Andreas Rheinhardt wrote:
James Almer:
On 1/31/2024 3:08 PM, Andreas Rheinhardt wrote:
James Almer:
This will be used to support tiled image formats like HEIF.
Signed-off-by: James Almer
---
libavformat/avformat.c | 5 +++
libavformat/avformat.h | 100 +
libavformat/dump.c | 29
libavformat/options.c | 32 +
4 files changed, 166 insertions(+)
diff --git a/libavformat/avformat.c b/libavformat/avformat.c
index 8e8c6fbe55..32ef440207 100644
--- a/libavformat/avformat.c
+++ b/libavformat/avformat.c
@@ -100,6 +100,11 @@ void ff_free_stream_group(AVStreamGroup **pstg)
av_iamf_mix_presentation_free(&stg->params.iamf_mix_presentation);
break;
}
+ case AV_STREAM_GROUP_PARAMS_TILE_GRID:
+ av_opt_free(stg->params.tile_grid);
+ av_freep(&stg->params.tile_grid->offsets);
+ av_freep(&stg->params.tile_grid);
+ break;
default:
break;
}
diff --git a/libavformat/avformat.h b/libavformat/avformat.h
index 5d0fe82250..6577f13ef1 100644
--- a/libavformat/avformat.h
+++ b/libavformat/avformat.h
@@ -1018,10 +1018,109 @@ typedef struct AVStream {
int pts_wrap_bits;
} AVStream;
+/**
+ * AVStreamGroupTileGrid holds information on how to combine several
+ * independent images on a single grid for presentation. None of the
tiles may
+ * overlap inside the grid.
+ *
+ * The following is an example of a simple grid with 3 rows and 4
columns:
+ *
+ * +---+---+---+---+
+ * | 0 | 1 | 2 | 3 |
+ * +---+---+---+---+
+ * | 4 | 5 | 6 | 7 |
+ * +---+---+---+---+
+ * | 8 | 9 |10 |11 |
+ * +---+---+---+---+
+ *
+ * Assuming all tiles have a dimension of 512x512, the
+ * @ref AVStreamGroupTileGrid.offsets "offset" of the topleft pixel of
+ * the first @ref AVStreamGroup.streams "stream" in the group is
"0,0", the
+ * @ref AVStreamGroupTileGrid.offsets "offset" of the topleft pixel of
+ * the second @ref AVStreamGroup.streams "stream" in the group is
"512,0", the
+ * @ref AVStreamGroupTileGrid.offsets "offset" of the topleft pixel of
+ * the fifth @ref AVStreamGroup.streams "stream" in the group is
"0,512", the
+ * @ref AVStreamGroupTileGrid.offsets "offset", of the topleft pixel of
+ * the sixth @ref AVStreamGroup.streams "stream" in the group is
"512,512",
+ * etc.
+ *
+ * sizeof(AVStreamGroupTileGrid) is not a part of the ABI. No new
fields may be
+ * added to this struct without a major version bump.
This is inconsistent. I think you mean that sizeof is part of the ABI.
No? It's not a part of the ABI because AVStreamGroupTileGrid must not be
ever used on stack, or allocated by anything other than AVStreamGroup.
That way we can add fields to it without waiting for a major bump.
"No new fields may be added to this struct without a major version bump"
Ah, i see. Copy paste fail. Will remove that part.
___
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/4 v6] avformat: add a Tile Grid stream group type
James Almer:
> On 1/31/2024 3:08 PM, Andreas Rheinhardt wrote:
>> James Almer:
>>> This will be used to support tiled image formats like HEIF.
>>>
>>> Signed-off-by: James Almer
>>> ---
>>> libavformat/avformat.c | 5 +++
>>> libavformat/avformat.h | 100 +
>>> libavformat/dump.c | 29
>>> libavformat/options.c | 32 +
>>> 4 files changed, 166 insertions(+)
>>>
>>> diff --git a/libavformat/avformat.c b/libavformat/avformat.c
>>> index 8e8c6fbe55..32ef440207 100644
>>> --- a/libavformat/avformat.c
>>> +++ b/libavformat/avformat.c
>>> @@ -100,6 +100,11 @@ void ff_free_stream_group(AVStreamGroup **pstg)
>>>
>>> av_iamf_mix_presentation_free(&stg->params.iamf_mix_presentation);
>>> break;
>>> }
>>> + case AV_STREAM_GROUP_PARAMS_TILE_GRID:
>>> + av_opt_free(stg->params.tile_grid);
>>> + av_freep(&stg->params.tile_grid->offsets);
>>> + av_freep(&stg->params.tile_grid);
>>> + break;
>>> default:
>>> break;
>>> }
>>> diff --git a/libavformat/avformat.h b/libavformat/avformat.h
>>> index 5d0fe82250..6577f13ef1 100644
>>> --- a/libavformat/avformat.h
>>> +++ b/libavformat/avformat.h
>>> @@ -1018,10 +1018,109 @@ typedef struct AVStream {
>>> int pts_wrap_bits;
>>> } AVStream;
>>> +/**
>>> + * AVStreamGroupTileGrid holds information on how to combine several
>>> + * independent images on a single grid for presentation. None of the
>>> tiles may
>>> + * overlap inside the grid.
>>> + *
>>> + * The following is an example of a simple grid with 3 rows and 4
>>> columns:
>>> + *
>>> + * +---+---+---+---+
>>> + * | 0 | 1 | 2 | 3 |
>>> + * +---+---+---+---+
>>> + * | 4 | 5 | 6 | 7 |
>>> + * +---+---+---+---+
>>> + * | 8 | 9 |10 |11 |
>>> + * +---+---+---+---+
>>> + *
>>> + * Assuming all tiles have a dimension of 512x512, the
>>> + * @ref AVStreamGroupTileGrid.offsets "offset" of the topleft pixel of
>>> + * the first @ref AVStreamGroup.streams "stream" in the group is
>>> "0,0", the
>>> + * @ref AVStreamGroupTileGrid.offsets "offset" of the topleft pixel of
>>> + * the second @ref AVStreamGroup.streams "stream" in the group is
>>> "512,0", the
>>> + * @ref AVStreamGroupTileGrid.offsets "offset" of the topleft pixel of
>>> + * the fifth @ref AVStreamGroup.streams "stream" in the group is
>>> "0,512", the
>>> + * @ref AVStreamGroupTileGrid.offsets "offset", of the topleft pixel of
>>> + * the sixth @ref AVStreamGroup.streams "stream" in the group is
>>> "512,512",
>>> + * etc.
>>> + *
>>> + * sizeof(AVStreamGroupTileGrid) is not a part of the ABI. No new
>>> fields may be
>>> + * added to this struct without a major version bump.
>> This is inconsistent. I think you mean that sizeof is part of the ABI.
>
> No? It's not a part of the ABI because AVStreamGroupTileGrid must not be
> ever used on stack, or allocated by anything other than AVStreamGroup.
> That way we can add fields to it without waiting for a major bump.
"No new fields may be added to this struct without a major version bump"
- 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] Meeting at FOSDEM
Hi everybody, Sorry I can't be at FOSDEM to meet you all again. Unfortunately it always falls on a weekend I have to be available at home for work. -- 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] Sovereign Tech Fund
On Wed, 31 Jan 2024 at 18:03, Michael Niedermayer wrote: > Hi Jonatas, Remi > > _THIS_ reply shows why i LOVE SPI > > I mean this is transparency, anyone try to get something similar from a > corporation > > Just in the last 48h i have seen a reminder from a CEO about "shareholder > agreement" > and privacy > If you want transparency, where is the agreement between SPI and STF? Where is the agreement for the NAB booth? 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/4 v6] avformat: add a Tile Grid stream group type
On 1/31/2024 3:08 PM, Andreas Rheinhardt wrote:
James Almer:
This will be used to support tiled image formats like HEIF.
Signed-off-by: James Almer
---
libavformat/avformat.c | 5 +++
libavformat/avformat.h | 100 +
libavformat/dump.c | 29
libavformat/options.c | 32 +
4 files changed, 166 insertions(+)
diff --git a/libavformat/avformat.c b/libavformat/avformat.c
index 8e8c6fbe55..32ef440207 100644
--- a/libavformat/avformat.c
+++ b/libavformat/avformat.c
@@ -100,6 +100,11 @@ void ff_free_stream_group(AVStreamGroup **pstg)
av_iamf_mix_presentation_free(&stg->params.iamf_mix_presentation);
break;
}
+case AV_STREAM_GROUP_PARAMS_TILE_GRID:
+av_opt_free(stg->params.tile_grid);
+av_freep(&stg->params.tile_grid->offsets);
+av_freep(&stg->params.tile_grid);
+break;
default:
break;
}
diff --git a/libavformat/avformat.h b/libavformat/avformat.h
index 5d0fe82250..6577f13ef1 100644
--- a/libavformat/avformat.h
+++ b/libavformat/avformat.h
@@ -1018,10 +1018,109 @@ typedef struct AVStream {
int pts_wrap_bits;
} AVStream;
+/**
+ * AVStreamGroupTileGrid holds information on how to combine several
+ * independent images on a single grid for presentation. None of the tiles may
+ * overlap inside the grid.
+ *
+ * The following is an example of a simple grid with 3 rows and 4 columns:
+ *
+ * +---+---+---+---+
+ * | 0 | 1 | 2 | 3 |
+ * +---+---+---+---+
+ * | 4 | 5 | 6 | 7 |
+ * +---+---+---+---+
+ * | 8 | 9 |10 |11 |
+ * +---+---+---+---+
+ *
+ * Assuming all tiles have a dimension of 512x512, the
+ * @ref AVStreamGroupTileGrid.offsets "offset" of the topleft pixel of
+ * the first @ref AVStreamGroup.streams "stream" in the group is "0,0", the
+ * @ref AVStreamGroupTileGrid.offsets "offset" of the topleft pixel of
+ * the second @ref AVStreamGroup.streams "stream" in the group is "512,0", the
+ * @ref AVStreamGroupTileGrid.offsets "offset" of the topleft pixel of
+ * the fifth @ref AVStreamGroup.streams "stream" in the group is "0,512", the
+ * @ref AVStreamGroupTileGrid.offsets "offset", of the topleft pixel of
+ * the sixth @ref AVStreamGroup.streams "stream" in the group is "512,512",
+ * etc.
+ *
+ * sizeof(AVStreamGroupTileGrid) is not a part of the ABI. No new fields may be
+ * added to this struct without a major version bump.
This is inconsistent. I think you mean that sizeof is part of the ABI.
No? It's not a part of the ABI because AVStreamGroupTileGrid must not be
ever used on stack, or allocated by anything other than AVStreamGroup.
That way we can add fields to it without waiting for a major bump.
___
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/4 v6] avformat: add a Tile Grid stream group type
James Almer:
> This will be used to support tiled image formats like HEIF.
>
> Signed-off-by: James Almer
> ---
> libavformat/avformat.c | 5 +++
> libavformat/avformat.h | 100 +
> libavformat/dump.c | 29
> libavformat/options.c | 32 +
> 4 files changed, 166 insertions(+)
>
> diff --git a/libavformat/avformat.c b/libavformat/avformat.c
> index 8e8c6fbe55..32ef440207 100644
> --- a/libavformat/avformat.c
> +++ b/libavformat/avformat.c
> @@ -100,6 +100,11 @@ void ff_free_stream_group(AVStreamGroup **pstg)
> av_iamf_mix_presentation_free(&stg->params.iamf_mix_presentation);
> break;
> }
> +case AV_STREAM_GROUP_PARAMS_TILE_GRID:
> +av_opt_free(stg->params.tile_grid);
> +av_freep(&stg->params.tile_grid->offsets);
> +av_freep(&stg->params.tile_grid);
> +break;
> default:
> break;
> }
> diff --git a/libavformat/avformat.h b/libavformat/avformat.h
> index 5d0fe82250..6577f13ef1 100644
> --- a/libavformat/avformat.h
> +++ b/libavformat/avformat.h
> @@ -1018,10 +1018,109 @@ typedef struct AVStream {
> int pts_wrap_bits;
> } AVStream;
>
> +/**
> + * AVStreamGroupTileGrid holds information on how to combine several
> + * independent images on a single grid for presentation. None of the tiles
> may
> + * overlap inside the grid.
> + *
> + * The following is an example of a simple grid with 3 rows and 4 columns:
> + *
> + * +---+---+---+---+
> + * | 0 | 1 | 2 | 3 |
> + * +---+---+---+---+
> + * | 4 | 5 | 6 | 7 |
> + * +---+---+---+---+
> + * | 8 | 9 |10 |11 |
> + * +---+---+---+---+
> + *
> + * Assuming all tiles have a dimension of 512x512, the
> + * @ref AVStreamGroupTileGrid.offsets "offset" of the topleft pixel of
> + * the first @ref AVStreamGroup.streams "stream" in the group is "0,0", the
> + * @ref AVStreamGroupTileGrid.offsets "offset" of the topleft pixel of
> + * the second @ref AVStreamGroup.streams "stream" in the group is "512,0",
> the
> + * @ref AVStreamGroupTileGrid.offsets "offset" of the topleft pixel of
> + * the fifth @ref AVStreamGroup.streams "stream" in the group is "0,512", the
> + * @ref AVStreamGroupTileGrid.offsets "offset", of the topleft pixel of
> + * the sixth @ref AVStreamGroup.streams "stream" in the group is "512,512",
> + * etc.
> + *
> + * sizeof(AVStreamGroupTileGrid) is not a part of the ABI. No new fields may
> be
> + * added to this struct without a major version bump.
This is inconsistent. I think you mean that sizeof is part of the ABI.
> + */
> +typedef struct AVStreamGroupTileGrid {
> +const AVClass *av_class;
> +
> +/**
> + * Width of the final image in the grid.
> + *
> + * Must be > 0.
> + */
> +int coded_width;
> +/**
> + * Width of the final image in the grid.
> + *
> + * Must be > 0.
> + */
> +int coded_height;
> +
> +/**
> + * An @ref AVStreamGroup.nb_streams "nb_streams" sized array of offsets
> in
> + * pixels from the topleft edge of the grid, indicating where each stream
> + * should be placed.
> + * It must be allocated with the av_malloc() family of functions.
> + *
> + * - demuxing: set by libavformat, must not be modified by the caller.
> + * - muxing: set by the caller before avformat_write_header().
> + *
> + * Freed by libavformat in avformat_free_context().
> + */
> +struct {
> +int x;
> +int y;
> +} *offsets;
> +
> +/**
> + * Offset in pixels from the left edge of the grid where the actual image
> + * meant for presentation starts.
> + *
> + * This field must be >= 0 and <= @ref coded_width.
> + */
> +int horizontal_offset;
> +/**
> + * Offset in pixels from the top edge of the grid where the actual image
> + * meant for presentation starts.
> + *
> + * This field must be >= 0 and <= @ref coded_height.
> + */
> +int vertical_offset;
> +
> +/**
> + * Width of the final image for presentation.
> + *
> + * Must be > 0 and <= (@ref coded_width - @ref horizontal_offset).
> + * When it's not equal to (@ref coded_width - @ref horizontal_offset),
> the
> + * result of (@ref coded_width - width - @ref horizontal_offset) is the
> + * amount amount of pixels to be cropped from the right edge of the
> + * final image before presentation.
> + */
> +int width;
> +/**
> + * Height of the final image for presentation.
> + *
> + * Must be > 0 and <= (@ref coded_height - @ref vertical_offset).
> + * When it's not equal to (@ref coded_height - @ref vertical_offset), the
> + * result of (@ref coded_height - height - @ref vertical_offset) is the
> + * amount amount of pixels to be cropped from the bototm edge of the
> + * final image before presentation.
> + */
> +int height;
> +} AVStreamGroupTileGrid;
> +
> enum AVStreamGroupParamsType {
> AV_STRE
Re: [FFmpeg-devel] [PATCH 1/4 v3] avformat/mov: ignore item boxes for animated heif
On 1/31/2024 3:06 PM, Andreas Rheinhardt wrote:
James Almer:
Fixes a regression since d9fed9df2a, where the single animated stream would
be exported twice as two independent streams.
Signed-off-by: James Almer
---
libavformat/isom.h | 1 +
libavformat/mov.c | 147 ++---
2 files changed, 99 insertions(+), 49 deletions(-)
diff --git a/libavformat/isom.h b/libavformat/isom.h
index 2cf456fee1..21caaac256 100644
--- a/libavformat/isom.h
+++ b/libavformat/isom.h
@@ -280,6 +280,7 @@ typedef struct MOVContext {
int64_t duration; ///< duration of the longest track
int found_moov; ///< 'moov' atom has been found
int found_iloc; ///< 'iloc' atom has been found
+int found_iinf; ///< 'iinf' atom has been found
int found_mdat; ///< 'mdat' atom has been found
int found_hdlr_mdta; ///< 'hdlr' atom with type 'mdta' has been found
int trak_index; ///< Index of the current 'trak'
diff --git a/libavformat/mov.c b/libavformat/mov.c
index cf931d4594..af95e1f662 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -81,6 +81,7 @@ typedef struct MOVParseTableEntry {
static int mov_read_default(MOVContext *c, AVIOContext *pb, MOVAtom atom);
static int mov_read_mfra(MOVContext *c, AVIOContext *f);
+static void mov_free_stream_context(AVFormatContext *s, AVStream *st);
static int64_t add_ctts_entry(MOVCtts** ctts_data, unsigned int* ctts_count,
unsigned int* allocated_size,
int count, int duration);
@@ -4644,6 +4645,23 @@ static int mov_read_trak(MOVContext *c, AVIOContext *pb, MOVAtom atom)
MOVStreamContext *sc;
int ret;
+if (c->found_iinf) {
+// * For animated heif, if the iinf box showed up before the moov
+// box, we need to clear all the streams read in the former.
+for (int i = c->heif_info_size - 1; i >= 0; i--) {
+HEIFItem *item = &c->heif_info[i];
+
+if (!item->st)
+continue;
+
+mov_free_stream_context(c->fc, item->st);
+ff_remove_stream(c->fc, item->st);
+}
+av_freep(&c->heif_info);
+c->heif_info_size = 0;
+c->found_iinf = c->found_iloc = 0;
+}
+
st = avformat_new_stream(c->fc, NULL);
if (!st) return AVERROR(ENOMEM);
st->id = -1;
@@ -7773,8 +7791,9 @@ static int mov_read_iloc(MOVContext *c, AVIOContext *pb,
MOVAtom atom)
uint64_t base_offset, extent_offset, extent_length;
uint8_t value;
-if (c->found_iloc) {
-av_log(c->fc, AV_LOG_INFO, "Duplicate iloc box found\n");
+if (c->found_moov) {
+// * For animated heif, we don't care about the iloc box as all the
+// necessary information can be found in the moov box.
return 0;
}
@@ -7896,6 +7915,16 @@ static int mov_read_iinf(MOVContext *c, AVIOContext *pb, MOVAtom atom)
int entry_count;
int version, ret;
+if (c->found_iinf) {
+av_log(c->fc, AV_LOG_WARNING, "Duplicate iinf box found\n");
+return 0;
+}
+if (c->found_moov) {
+// * For animated heif, we don't care about the iinf box as all the
+// necessary information can be found in the moov box.
+return 0;
+}
+
version = avio_r8(pb);
avio_rb24(pb); // flags.
entry_count = version ? avio_rb32(pb) : avio_rb16(pb);
@@ -7919,6 +7948,7 @@ static int mov_read_iinf(MOVContext *c, AVIOContext *pb,
MOVAtom atom)
return ret;
}
+c->found_iinf = 1;
return 0;
}
@@ -7932,6 +7962,13 @@ static int mov_read_iref(MOVContext *c, AVIOContext *pb, MOVAtom atom)
static int mov_read_ispe(MOVContext *c, AVIOContext *pb, MOVAtom atom)
{
uint32_t width, height;
+
+if (c->found_moov) {
+// * For animated heif, we don't care about the ispe box as all the
+// necessary information can be found in the moov box.
+return 0;
+}
+
avio_r8(pb); /* version */
avio_rb24(pb); /* flags */
width = avio_rb32(pb);
@@ -7966,6 +8003,12 @@ static int mov_read_iprp(MOVContext *c, AVIOContext *pb,
MOVAtom atom)
int version, flags;
int ret;
+if (c->found_moov) {
+// * For animated heif, we don't care about the iprp box as all the
+// necessary information can be found in the moov box.
+return 0;
+}
+
a.size = avio_rb32(pb);
a.type = avio_rl32(pb);
@@ -8587,6 +8630,58 @@ static void mov_free_encryption_index(MOVEncryptionIndex **index) {
av_freep(index);
}
+static void mov_free_stream_context(AVFormatContext *s, AVStream *st)
+{
+MOVStreamContext *sc = st->priv_data;
+
+if (!sc)
+return;
+
+av_freep(&sc->ctts_data);
+for (int i = 0; i < sc->drefs_count; i++) {
+av_freep(&sc->drefs[i].path);
+av_freep(&sc->drefs[i].dir);
+}
+av_freep(&sc->drefs);
+
+
Re: [FFmpeg-devel] [PATCH 1/4 v3] avformat/mov: ignore item boxes for animated heif
James Almer:
> Fixes a regression since d9fed9df2a, where the single animated stream would
> be exported twice as two independent streams.
>
> Signed-off-by: James Almer
> ---
> libavformat/isom.h | 1 +
> libavformat/mov.c | 147 ++---
> 2 files changed, 99 insertions(+), 49 deletions(-)
>
> diff --git a/libavformat/isom.h b/libavformat/isom.h
> index 2cf456fee1..21caaac256 100644
> --- a/libavformat/isom.h
> +++ b/libavformat/isom.h
> @@ -280,6 +280,7 @@ typedef struct MOVContext {
> int64_t duration; ///< duration of the longest track
> int found_moov; ///< 'moov' atom has been found
> int found_iloc; ///< 'iloc' atom has been found
> +int found_iinf; ///< 'iinf' atom has been found
> int found_mdat; ///< 'mdat' atom has been found
> int found_hdlr_mdta; ///< 'hdlr' atom with type 'mdta' has been found
> int trak_index; ///< Index of the current 'trak'
> diff --git a/libavformat/mov.c b/libavformat/mov.c
> index cf931d4594..af95e1f662 100644
> --- a/libavformat/mov.c
> +++ b/libavformat/mov.c
> @@ -81,6 +81,7 @@ typedef struct MOVParseTableEntry {
>
> static int mov_read_default(MOVContext *c, AVIOContext *pb, MOVAtom atom);
> static int mov_read_mfra(MOVContext *c, AVIOContext *f);
> +static void mov_free_stream_context(AVFormatContext *s, AVStream *st);
> static int64_t add_ctts_entry(MOVCtts** ctts_data, unsigned int* ctts_count,
> unsigned int* allocated_size,
>int count, int duration);
>
> @@ -4644,6 +4645,23 @@ static int mov_read_trak(MOVContext *c, AVIOContext
> *pb, MOVAtom atom)
> MOVStreamContext *sc;
> int ret;
>
> +if (c->found_iinf) {
> +// * For animated heif, if the iinf box showed up before the moov
> +// box, we need to clear all the streams read in the former.
> +for (int i = c->heif_info_size - 1; i >= 0; i--) {
> +HEIFItem *item = &c->heif_info[i];
> +
> +if (!item->st)
> +continue;
> +
> +mov_free_stream_context(c->fc, item->st);
> +ff_remove_stream(c->fc, item->st);
> +}
> +av_freep(&c->heif_info);
> +c->heif_info_size = 0;
> +c->found_iinf = c->found_iloc = 0;
> +}
> +
> st = avformat_new_stream(c->fc, NULL);
> if (!st) return AVERROR(ENOMEM);
> st->id = -1;
> @@ -7773,8 +7791,9 @@ static int mov_read_iloc(MOVContext *c, AVIOContext
> *pb, MOVAtom atom)
> uint64_t base_offset, extent_offset, extent_length;
> uint8_t value;
>
> -if (c->found_iloc) {
> -av_log(c->fc, AV_LOG_INFO, "Duplicate iloc box found\n");
> +if (c->found_moov) {
> +// * For animated heif, we don't care about the iloc box as all the
> +// necessary information can be found in the moov box.
> return 0;
> }
>
> @@ -7896,6 +7915,16 @@ static int mov_read_iinf(MOVContext *c, AVIOContext
> *pb, MOVAtom atom)
> int entry_count;
> int version, ret;
>
> +if (c->found_iinf) {
> +av_log(c->fc, AV_LOG_WARNING, "Duplicate iinf box found\n");
> +return 0;
> +}
> +if (c->found_moov) {
> +// * For animated heif, we don't care about the iinf box as all the
> +// necessary information can be found in the moov box.
> +return 0;
> +}
> +
> version = avio_r8(pb);
> avio_rb24(pb); // flags.
> entry_count = version ? avio_rb32(pb) : avio_rb16(pb);
> @@ -7919,6 +7948,7 @@ static int mov_read_iinf(MOVContext *c, AVIOContext
> *pb, MOVAtom atom)
> return ret;
> }
>
> +c->found_iinf = 1;
> return 0;
> }
>
> @@ -7932,6 +7962,13 @@ static int mov_read_iref(MOVContext *c, AVIOContext
> *pb, MOVAtom atom)
> static int mov_read_ispe(MOVContext *c, AVIOContext *pb, MOVAtom atom)
> {
> uint32_t width, height;
> +
> +if (c->found_moov) {
> +// * For animated heif, we don't care about the ispe box as all the
> +// necessary information can be found in the moov box.
> +return 0;
> +}
> +
> avio_r8(pb); /* version */
> avio_rb24(pb); /* flags */
> width = avio_rb32(pb);
> @@ -7966,6 +8003,12 @@ static int mov_read_iprp(MOVContext *c, AVIOContext
> *pb, MOVAtom atom)
> int version, flags;
> int ret;
>
> +if (c->found_moov) {
> +// * For animated heif, we don't care about the iprp box as all the
> +// necessary information can be found in the moov box.
> +return 0;
> +}
> +
> a.size = avio_rb32(pb);
> a.type = avio_rl32(pb);
>
> @@ -8587,6 +8630,58 @@ static void
> mov_free_encryption_index(MOVEncryptionIndex **index) {
> av_freep(index);
> }
>
> +static void mov_free_stream_context(AVFormatContext *s, AVStream *st)
> +{
> +MOVStreamContext *sc = st->priv_data;
> +
> +if (!sc)
> +return;
> +
> +av_freep(&sc->ctts_dat
Re: [FFmpeg-devel] Sovereign Tech Fund
Hi Jonatas, Remi _THIS_ reply shows why i LOVE SPI I mean this is transparency, anyone try to get something similar from a corporation Just in the last 48h i have seen a reminder from a CEO about "shareholder agreement" and privacy thx On Wed, Jan 31, 2024 at 05:04:20PM +, Jonatas L. Nogueira via ffmpeg-devel wrote: [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB If you fake or manipulate statistics in a paper in physics you will never get a job again. If you fake or manipulate statistics in a paper in medicin you will get a job for life at the pharma industry. 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 4/4] lavc/rv34dsp: R-V V rv34_idct_dc_add
Fixed the rv32 break in this reply
flow gg 于2024年1月31日周三 20:01写道：
>
>
From 0874f319e1c26aa0eeb5ed0d4e00d29aec4c5af8 Mon Sep 17 00:00:00 2001
From: sunyuechi
Date: Wed, 31 Jan 2024 19:04:11 +0800
Subject: [PATCH 4/4] lavc/rv34dsp: R-V V rv34_idct_dc_add
C908:
rv34_idct_dc_add_c: 134.7
rv34_idct_dc_add_rvv_i32: 45.5
---
libavcodec/riscv/rv34dsp_init.c | 2 ++
libavcodec/riscv/rv34dsp_rvv.S | 20
2 files changed, 22 insertions(+)
diff --git a/libavcodec/riscv/rv34dsp_init.c b/libavcodec/riscv/rv34dsp_init.c
index 852c8ad9a8..7dcadc7e43 100644
--- a/libavcodec/riscv/rv34dsp_init.c
+++ b/libavcodec/riscv/rv34dsp_init.c
@@ -26,6 +26,7 @@
#include "libavcodec/rv34dsp.h"
void ff_rv34_inv_transform_dc_rvv(int16_t *block);
+void ff_rv34_idct_dc_add_rvv(uint8_t *dst, ptrdiff_t stride, int dc);
av_cold void ff_rv34dsp_init_riscv(RV34DSPContext *c)
{
@@ -34,6 +35,7 @@ av_cold void ff_rv34dsp_init_riscv(RV34DSPContext *c)
if (flags & AV_CPU_FLAG_RVV_I32 && ff_get_rv_vlenb() >= 16) {
c->rv34_inv_transform_dc = ff_rv34_inv_transform_dc_rvv;
+c->rv34_idct_dc_add = ff_rv34_idct_dc_add_rvv;
}
#endif
}
diff --git a/libavcodec/riscv/rv34dsp_rvv.S b/libavcodec/riscv/rv34dsp_rvv.S
index 4b7a071f7c..450226f742 100644
--- a/libavcodec/riscv/rv34dsp_rvv.S
+++ b/libavcodec/riscv/rv34dsp_rvv.S
@@ -36,3 +36,23 @@ func ff_rv34_inv_transform_dc_rvv, zve32x
ret
endfunc
+
+func ff_rv34_idct_dc_add_rvv, zve32x
+vsetivli zero, 4, e8, mf4, ta, ma
+vlse32.v v0, (a0), a1
+lit1, 169
+mul t1, t1, a2
+lia2, 255
+addi t1, t1, 512
+srai t1, t1, 10
+vsetivli zero, 4*4, e16, m2, ta, ma
+vzext.vf2 v2, v0
+vadd.vx v2, v2, t1
+vmax.vx v2, v2, zero
+vsetvli zero, zero, e8, m1, ta, ma
+vnclipu.wiv0, v2, 0
+vsetivli zero, 4, e8, mf4, ta, ma
+vsse32.v v0, (a0), a1
+
+ret
+endfunc
--
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".
Re: [FFmpeg-devel] Sovereign Tech Fund
Hi Rémi On Wed, Jan 31, 2024 at 06:10:57PM +0200, Rémi Denis-Courmont wrote: [...] > This is further aggravated by the context that Michael brought forward the > idea of funding developers through SPI 3 months ago (in actual Earth units). > From your statement, I have to infer that Thilo, Michael and SPI already knew > of the STF plan and concealed that key piece of contextual information back > then. Iam evil I had talked with ronald and heared about the "sustainability" "need" and from that made several plans. One i posted and was flamed because it sounded similar to a talk on demuxed. (I think using the word "sustainability") One of the other ideas was indeed STF: look: -rw-r- 1 michael michael 666 Okt 26 11:39 sustainability-consulting.txt -rw-r- 1 michael michael 666 Okt 26 11:39 sustainability-consulting.txt~ -rw-r- 1 michael michael 2604 Dez 27 00:13 sustainability-license.txt -rw-r- 1 michael michael 2504 Dez 27 00:13 sustainability-license.txt~ -rw-r- 1 michael michael 801 Nov 15 09:47 sustainability-notes2.txt -rw-r- 1 michael michael 801 Nov 15 09:47 sustainability-notes2.txt~ -rw-r- 1 michael michael 319 Okt 26 11:49 sustainability-other.txt -rw-r- 1 michael michael 319 Okt 26 11:49 sustainability-other.txt~ -rw-r- 1 michael michael 1828 Okt 26 13:46 sustainability-spi.txt -rw-r- 1 michael michael 1828 Okt 26 13:46 sustainability-spi.txt~ -rw-r- 1 michael michael 9812 Jan 12 23:45 sustainability-stf.txt -rw-r- 1 michael michael 7450 Jan 12 23:45 sustainability-stf.txt~ I did intend to leave some time between posting each idea so people could reload their guns properly but as life goes things get delayed, one is busy and also in the STF case there was some push towards waiting several of these ideas i still had no time to properly spell out and post Also just because i wrote something doesnt mean these are finished, presentable ideas All that said, its not entirely uncommon that people publically hear of things months after someone knew of something about it. You can compare this to the bloomberg donation and the open collective account that was created for ffmpeg by jb: https://opencollective.com/ffmpeg There was no public question before that account was created, I know because some people where privatly upset about that. thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB I do not agree with what you have to say, but I'll defend to the death your right to say it. -- Voltaire 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 2/4] lavc/rv34dsp: R-V V rv34_inv_transform_dc
> Also fractional multipler should never be smaller than the ratio of the
> specified element size to the largest element size used in the function.
Here
> it is largelly inconsequential, but for instance "e32, mf4" and "e64,
mf2" are
> invalid.
Thanks, I indeed almost forgot about this part
> I think this breaks the build for RV32
Okay, modified in the reply
> it lacks checks for the vector length.
In the rv34dsp_init.c, there's a check with ff_get_rv_vlenb() >= 16.
Doesn't this already check the vector length?
Rémi Denis-Courmont 于2024年2月1日周四 00:31写道：
> Hi,
>
> I think this breaks the build for RV32, and it lacks checks for the vector
> length.
>
> Also fractional multipler should never be smaller than the ratio of the
> specified element size to the largest element size used in the function.
> Here
> it is largelly inconsequential, but for instance "e32, mf4" and "e64, mf2"
> are
> invalid.
>
> --
> 雷米‧德尼-库尔蒙
> http://www.remlab.net/
>
>
>
> ___
> 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 538ff8b20ead25d95b8507e318207b19d89a63c2 Mon Sep 17 00:00:00 2001
From: sunyuechi
Date: Wed, 31 Jan 2024 19:03:20 +0800
Subject: [PATCH 2/4] lavc/rv34dsp: R-V V rv34_inv_transform_dc
C908:
rv34_inv_transform_dc_c: 35.5
rv34_inv_transform_dc_rvv_i32: 27.0
---
libavcodec/riscv/Makefile | 2 ++
libavcodec/riscv/rv34dsp_init.c | 39 +
libavcodec/riscv/rv34dsp_rvv.S | 38
libavcodec/rv34dsp.c| 2 ++
libavcodec/rv34dsp.h| 1 +
5 files changed, 82 insertions(+)
create mode 100644 libavcodec/riscv/rv34dsp_init.c
create mode 100644 libavcodec/riscv/rv34dsp_rvv.S
diff --git a/libavcodec/riscv/Makefile b/libavcodec/riscv/Makefile
index e15aba58f4..ffe6631cf2 100644
--- a/libavcodec/riscv/Makefile
+++ b/libavcodec/riscv/Makefile
@@ -44,6 +44,8 @@ RVV-OBJS-$(CONFIG_OPUS_DECODER) += riscv/opusdsp_rvv.o
OBJS-$(CONFIG_PIXBLOCKDSP) += riscv/pixblockdsp_init.o
RV-OBJS-$(CONFIG_PIXBLOCKDSP) += riscv/pixblockdsp_rvi.o
RVV-OBJS-$(CONFIG_PIXBLOCKDSP) += riscv/pixblockdsp_rvv.o
+OBJS-$(CONFIG_RV34DSP) += riscv/rv34dsp_init.o
+RVV-OBJS-$(CONFIG_RV34DSP) += riscv/rv34dsp_rvv.o
OBJS-$(CONFIG_SVQ1_ENCODER) += riscv/svqenc_init.o
RVV-OBJS-$(CONFIG_SVQ1_ENCODER) += riscv/svqenc_rvv.o
OBJS-$(CONFIG_TAK_DECODER) += riscv/takdsp_init.o
diff --git a/libavcodec/riscv/rv34dsp_init.c b/libavcodec/riscv/rv34dsp_init.c
new file mode 100644
index 00..852c8ad9a8
--- /dev/null
+++ b/libavcodec/riscv/rv34dsp_init.c
@@ -0,0 +1,39 @@
+/*
+ * Copyright (c) 2024 Institue of Software Chinese Academy of Sciences (ISCAS).
+ *
+ * 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 "config.h"
+
+#include "libavutil/attributes.h"
+#include "libavutil/cpu.h"
+#include "libavutil/riscv/cpu.h"
+#include "libavcodec/rv34dsp.h"
+
+void ff_rv34_inv_transform_dc_rvv(int16_t *block);
+
+av_cold void ff_rv34dsp_init_riscv(RV34DSPContext *c)
+{
+#if HAVE_RVV
+int flags = av_get_cpu_flags();
+
+if (flags & AV_CPU_FLAG_RVV_I32 && ff_get_rv_vlenb() >= 16) {
+c->rv34_inv_transform_dc = ff_rv34_inv_transform_dc_rvv;
+}
+#endif
+}
diff --git a/libavcodec/riscv/rv34dsp_rvv.S b/libavcodec/riscv/rv34dsp_rvv.S
new file mode 100644
index 00..4b7a071f7c
--- /dev/null
+++ b/libavcodec/riscv/rv34dsp_rvv.S
@@ -0,0 +1,38 @@
+/*
+ * Copyright (c) 2024 Institue of Software Chinese Academy of Sciences (ISCAS).
+ *
+ * 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 Less
[FFmpeg-devel] [PATCH 4/4 v3] fate/mov: test remuxing all stream heif items
Signed-off-by: James Almer --- tests/fate/mov.mak | 2 +- tests/ref/fate/mov-heic-demux-still-image-multiple-items | 7 +++ 2 files changed, 8 insertions(+), 1 deletion(-) diff --git a/tests/fate/mov.mak b/tests/fate/mov.mak index f202f36d96..f549ae33d7 100644 --- a/tests/fate/mov.mak +++ b/tests/fate/mov.mak @@ -156,7 +156,7 @@ fate-mov-heic-demux-still-image-1-item: CMD = framemd5 -i $(TARGET_SAMPLES)/heif FATE_MOV_FFMPEG-$(call FRAMEMD5, MOV, HEVC, HEVC_PARSER) \ += fate-mov-heic-demux-still-image-multiple-items -fate-mov-heic-demux-still-image-multiple-items: CMD = framemd5 -i $(TARGET_SAMPLES)/heif-conformance/C003.heic -c:v copy +fate-mov-heic-demux-still-image-multiple-items: CMD = framemd5 -i $(TARGET_SAMPLES)/heif-conformance/C003.heic -c:v copy -map 0 # Resulting remux should have: # 1. first audio stream with AV_DISPOSITION_HEARING_IMPAIRED diff --git a/tests/ref/fate/mov-heic-demux-still-image-multiple-items b/tests/ref/fate/mov-heic-demux-still-image-multiple-items index c850c1ff9c..753cef267a 100644 --- a/tests/ref/fate/mov-heic-demux-still-image-multiple-items +++ b/tests/ref/fate/mov-heic-demux-still-image-multiple-items @@ -2,10 +2,17 @@ #version: 2 #hash: MD5 #extradata 0, 100, 5444bf01e03182c73ae957179d560f4d +#extradata 1, 100, 5444bf01e03182c73ae957179d560f4d #tb 0: 1/1 #media_type 0: video #codec_id 0: hevc #dimensions 0: 1280x720 #sar 0: 0/1 +#tb 1: 1/1 +#media_type 1: video +#codec_id 1: hevc +#dimensions 1: 1280x720 +#sar 1: 0/1 #stream#, dts,pts, duration, size, hash 0, 0, 0,1, 111554, 03ceabfab39afd2e2e796b9362111f32 +1, 0, 0,1, 112393, daa001d351c088a5bc328459e2501c95 -- 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 3/4 v4] avformat/mov: add support for tiled HEIF still images
Export each tile as its own stream, and the tiling information as a Stream
Group of type TILE_GRID.
This also enables exporting other stream items like thumbnails, which may be
present in non tiled HEIF images too. For those, the primary stream will be
tagged with the default disposition.
Based on a patch by Swaraj Hota
Signed-off-by: James Almer
---
libavformat/avformat.h | 6 +
libavformat/dump.c | 2 +
libavformat/isom.h | 9 +-
libavformat/mov.c | 369 +
4 files changed, 350 insertions(+), 36 deletions(-)
diff --git a/libavformat/avformat.h b/libavformat/avformat.h
index 6577f13ef1..cf7744ce2e 100644
--- a/libavformat/avformat.h
+++ b/libavformat/avformat.h
@@ -811,6 +811,12 @@ typedef struct AVIndexEntry {
* The video stream contains still images.
*/
#define AV_DISPOSITION_STILL_IMAGE (1 << 20)
+/**
+ * The video stream is intended to be merged with another stream before
+ * presentation.
+ * Used for example to signal the stream contains a tile from a HEIF grid.
+ */
+#define AV_DISPOSITION_TILE (1 << 21)
/**
* @return The AV_DISPOSITION_* flag corresponding to disp or a negative error
diff --git a/libavformat/dump.c b/libavformat/dump.c
index c9b7369bcd..de0e1d8b39 100644
--- a/libavformat/dump.c
+++ b/libavformat/dump.c
@@ -640,6 +640,8 @@ static void dump_stream_format(const AVFormatContext *ic,
int i,
av_log(NULL, log_level, " (still image)");
if (st->disposition & AV_DISPOSITION_NON_DIEGETIC)
av_log(NULL, log_level, " (non-diegetic)");
+if (st->disposition & AV_DISPOSITION_TILE)
+av_log(NULL, log_level, " (tile)");
av_log(NULL, log_level, "\n");
dump_metadata(NULL, st->metadata, extra_indent, log_level);
diff --git a/libavformat/isom.h b/libavformat/isom.h
index 21caaac256..8ce89059d3 100644
--- a/libavformat/isom.h
+++ b/libavformat/isom.h
@@ -267,10 +267,12 @@ typedef struct HEIFItem {
int item_id;
int64_t extent_length;
int64_t extent_offset;
-int64_t size;
+int tile_rows;
+int tile_cols;
int width;
int height;
int type;
+int is_idat_relative;
} HEIFItem;
typedef struct MOVContext {
@@ -336,6 +338,11 @@ typedef struct MOVContext {
int cur_item_id;
HEIFItem *heif_info;
int heif_info_size;
+int grid_item_id;
+int thmb_item_id;
+int16_t *tile_id_list;
+int nb_tiles;
+int64_t idat_offset;
int interleaved_read;
} MOVContext;
diff --git a/libavformat/mov.c b/libavformat/mov.c
index af95e1f662..b390c265ea 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -185,6 +185,30 @@ static int mov_read_mac_string(MOVContext *c, AVIOContext
*pb, int len,
return p - dst;
}
+static AVStream *get_curr_st(MOVContext *c)
+{
+AVStream *st = NULL;
+
+if (c->fc->nb_streams < 1)
+return NULL;
+
+for (int i = 0; i < c->heif_info_size; i++) {
+HEIFItem *item = &c->heif_info[i];
+
+if (!item->st)
+continue;
+if (item->st->id != c->cur_item_id)
+continue;
+
+st = item->st;
+break;
+}
+if (!st)
+st = c->fc->streams[c->fc->nb_streams-1];
+
+return st;
+}
+
static int mov_read_covr(MOVContext *c, AVIOContext *pb, int type, int len)
{
AVStream *st;
@@ -1767,9 +1791,9 @@ static int mov_read_colr(MOVContext *c, AVIOContext *pb,
MOVAtom atom)
uint16_t color_primaries, color_trc, color_matrix;
int ret;
-if (c->fc->nb_streams < 1)
+st = get_curr_st(c);
+if (!st)
return 0;
-st = c->fc->streams[c->fc->nb_streams - 1];
ret = ffio_read_size(pb, color_parameter_type, 4);
if (ret < 0)
@@ -2117,9 +2141,9 @@ static int mov_read_glbl(MOVContext *c, AVIOContext *pb,
MOVAtom atom)
AVStream *st;
int ret;
-if (c->fc->nb_streams < 1)
+st = get_curr_st(c);
+if (!st)
return 0;
-st = c->fc->streams[c->fc->nb_streams-1];
if ((uint64_t)atom.size > (1<<30))
return AVERROR_INVALIDDATA;
@@ -4951,12 +4975,10 @@ static int heif_add_stream(MOVContext *c, HEIFItem
*item)
st->codecpar->codec_type = AVMEDIA_TYPE_VIDEO;
st->codecpar->codec_id = mov_codec_id(st, item->type);
sc->ffindex = st->index;
-c->trak_index = st->index;
st->avg_frame_rate.num = st->avg_frame_rate.den = 1;
st->time_base.num = st->time_base.den = 1;
st->nb_frames = 1;
sc->time_scale = 1;
-sc = st->priv_data;
sc->pb = c->fc->pb;
sc->pb_is_copied = 1;
@@ -7784,11 +7806,55 @@ static int mov_read_pitm(MOVContext *c, AVIOContext
*pb, MOVAtom atom)
return atom.size;
}
+static int mov_read_idat(MOVContext *c, AVIOContext *pb, MOVAtom atom)
+{
+c->idat_offset = avio_tell(pb);
+return 0;
+}
+
+static int read_image_grid(AVFormatContext *s, AVStreamGroupTileGrid
*tile_grid,
+ HEIFItem *item)
+{
+MOVContext *c = s->priv_data;
+int64
[FFmpeg-devel] [PATCH 1/4 v3] avformat/mov: ignore item boxes for animated heif
Fixes a regression since d9fed9df2a, where the single animated stream would
be exported twice as two independent streams.
Signed-off-by: James Almer
---
libavformat/isom.h | 1 +
libavformat/mov.c | 147 ++---
2 files changed, 99 insertions(+), 49 deletions(-)
diff --git a/libavformat/isom.h b/libavformat/isom.h
index 2cf456fee1..21caaac256 100644
--- a/libavformat/isom.h
+++ b/libavformat/isom.h
@@ -280,6 +280,7 @@ typedef struct MOVContext {
int64_t duration; ///< duration of the longest track
int found_moov; ///< 'moov' atom has been found
int found_iloc; ///< 'iloc' atom has been found
+int found_iinf; ///< 'iinf' atom has been found
int found_mdat; ///< 'mdat' atom has been found
int found_hdlr_mdta; ///< 'hdlr' atom with type 'mdta' has been found
int trak_index; ///< Index of the current 'trak'
diff --git a/libavformat/mov.c b/libavformat/mov.c
index cf931d4594..af95e1f662 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -81,6 +81,7 @@ typedef struct MOVParseTableEntry {
static int mov_read_default(MOVContext *c, AVIOContext *pb, MOVAtom atom);
static int mov_read_mfra(MOVContext *c, AVIOContext *f);
+static void mov_free_stream_context(AVFormatContext *s, AVStream *st);
static int64_t add_ctts_entry(MOVCtts** ctts_data, unsigned int* ctts_count,
unsigned int* allocated_size,
int count, int duration);
@@ -4644,6 +4645,23 @@ static int mov_read_trak(MOVContext *c, AVIOContext *pb,
MOVAtom atom)
MOVStreamContext *sc;
int ret;
+if (c->found_iinf) {
+// * For animated heif, if the iinf box showed up before the moov
+// box, we need to clear all the streams read in the former.
+for (int i = c->heif_info_size - 1; i >= 0; i--) {
+HEIFItem *item = &c->heif_info[i];
+
+if (!item->st)
+continue;
+
+mov_free_stream_context(c->fc, item->st);
+ff_remove_stream(c->fc, item->st);
+}
+av_freep(&c->heif_info);
+c->heif_info_size = 0;
+c->found_iinf = c->found_iloc = 0;
+}
+
st = avformat_new_stream(c->fc, NULL);
if (!st) return AVERROR(ENOMEM);
st->id = -1;
@@ -7773,8 +7791,9 @@ static int mov_read_iloc(MOVContext *c, AVIOContext *pb,
MOVAtom atom)
uint64_t base_offset, extent_offset, extent_length;
uint8_t value;
-if (c->found_iloc) {
-av_log(c->fc, AV_LOG_INFO, "Duplicate iloc box found\n");
+if (c->found_moov) {
+// * For animated heif, we don't care about the iloc box as all the
+// necessary information can be found in the moov box.
return 0;
}
@@ -7896,6 +7915,16 @@ static int mov_read_iinf(MOVContext *c, AVIOContext *pb,
MOVAtom atom)
int entry_count;
int version, ret;
+if (c->found_iinf) {
+av_log(c->fc, AV_LOG_WARNING, "Duplicate iinf box found\n");
+return 0;
+}
+if (c->found_moov) {
+// * For animated heif, we don't care about the iinf box as all the
+// necessary information can be found in the moov box.
+return 0;
+}
+
version = avio_r8(pb);
avio_rb24(pb); // flags.
entry_count = version ? avio_rb32(pb) : avio_rb16(pb);
@@ -7919,6 +7948,7 @@ static int mov_read_iinf(MOVContext *c, AVIOContext *pb,
MOVAtom atom)
return ret;
}
+c->found_iinf = 1;
return 0;
}
@@ -7932,6 +7962,13 @@ static int mov_read_iref(MOVContext *c, AVIOContext *pb,
MOVAtom atom)
static int mov_read_ispe(MOVContext *c, AVIOContext *pb, MOVAtom atom)
{
uint32_t width, height;
+
+if (c->found_moov) {
+// * For animated heif, we don't care about the ispe box as all the
+// necessary information can be found in the moov box.
+return 0;
+}
+
avio_r8(pb); /* version */
avio_rb24(pb); /* flags */
width = avio_rb32(pb);
@@ -7966,6 +8003,12 @@ static int mov_read_iprp(MOVContext *c, AVIOContext *pb,
MOVAtom atom)
int version, flags;
int ret;
+if (c->found_moov) {
+// * For animated heif, we don't care about the iprp box as all the
+// necessary information can be found in the moov box.
+return 0;
+}
+
a.size = avio_rb32(pb);
a.type = avio_rl32(pb);
@@ -8587,6 +8630,58 @@ static void mov_free_encryption_index(MOVEncryptionIndex
**index) {
av_freep(index);
}
+static void mov_free_stream_context(AVFormatContext *s, AVStream *st)
+{
+MOVStreamContext *sc = st->priv_data;
+
+if (!sc)
+return;
+
+av_freep(&sc->ctts_data);
+for (int i = 0; i < sc->drefs_count; i++) {
+av_freep(&sc->drefs[i].path);
+av_freep(&sc->drefs[i].dir);
+}
+av_freep(&sc->drefs);
+
+sc->drefs_count = 0;
+
+if (!sc->pb_is_copied)
+ff_format_io_close(s, &sc->pb);
+
+sc->pb = NULL;
+av_fr
[FFmpeg-devel] [PATCH 2/4 v6] avformat: add a Tile Grid stream group type
This will be used to support tiled image formats like HEIF.
Signed-off-by: James Almer
---
libavformat/avformat.c | 5 +++
libavformat/avformat.h | 100 +
libavformat/dump.c | 29
libavformat/options.c | 32 +
4 files changed, 166 insertions(+)
diff --git a/libavformat/avformat.c b/libavformat/avformat.c
index 8e8c6fbe55..32ef440207 100644
--- a/libavformat/avformat.c
+++ b/libavformat/avformat.c
@@ -100,6 +100,11 @@ void ff_free_stream_group(AVStreamGroup **pstg)
av_iamf_mix_presentation_free(&stg->params.iamf_mix_presentation);
break;
}
+case AV_STREAM_GROUP_PARAMS_TILE_GRID:
+av_opt_free(stg->params.tile_grid);
+av_freep(&stg->params.tile_grid->offsets);
+av_freep(&stg->params.tile_grid);
+break;
default:
break;
}
diff --git a/libavformat/avformat.h b/libavformat/avformat.h
index 5d0fe82250..6577f13ef1 100644
--- a/libavformat/avformat.h
+++ b/libavformat/avformat.h
@@ -1018,10 +1018,109 @@ typedef struct AVStream {
int pts_wrap_bits;
} AVStream;
+/**
+ * AVStreamGroupTileGrid holds information on how to combine several
+ * independent images on a single grid for presentation. None of the tiles may
+ * overlap inside the grid.
+ *
+ * The following is an example of a simple grid with 3 rows and 4 columns:
+ *
+ * +---+---+---+---+
+ * | 0 | 1 | 2 | 3 |
+ * +---+---+---+---+
+ * | 4 | 5 | 6 | 7 |
+ * +---+---+---+---+
+ * | 8 | 9 |10 |11 |
+ * +---+---+---+---+
+ *
+ * Assuming all tiles have a dimension of 512x512, the
+ * @ref AVStreamGroupTileGrid.offsets "offset" of the topleft pixel of
+ * the first @ref AVStreamGroup.streams "stream" in the group is "0,0", the
+ * @ref AVStreamGroupTileGrid.offsets "offset" of the topleft pixel of
+ * the second @ref AVStreamGroup.streams "stream" in the group is "512,0", the
+ * @ref AVStreamGroupTileGrid.offsets "offset" of the topleft pixel of
+ * the fifth @ref AVStreamGroup.streams "stream" in the group is "0,512", the
+ * @ref AVStreamGroupTileGrid.offsets "offset", of the topleft pixel of
+ * the sixth @ref AVStreamGroup.streams "stream" in the group is "512,512",
+ * etc.
+ *
+ * sizeof(AVStreamGroupTileGrid) is not a part of the ABI. No new fields may be
+ * added to this struct without a major version bump.
+ */
+typedef struct AVStreamGroupTileGrid {
+const AVClass *av_class;
+
+/**
+ * Width of the final image in the grid.
+ *
+ * Must be > 0.
+ */
+int coded_width;
+/**
+ * Width of the final image in the grid.
+ *
+ * Must be > 0.
+ */
+int coded_height;
+
+/**
+ * An @ref AVStreamGroup.nb_streams "nb_streams" sized array of offsets in
+ * pixels from the topleft edge of the grid, indicating where each stream
+ * should be placed.
+ * It must be allocated with the av_malloc() family of functions.
+ *
+ * - demuxing: set by libavformat, must not be modified by the caller.
+ * - muxing: set by the caller before avformat_write_header().
+ *
+ * Freed by libavformat in avformat_free_context().
+ */
+struct {
+int x;
+int y;
+} *offsets;
+
+/**
+ * Offset in pixels from the left edge of the grid where the actual image
+ * meant for presentation starts.
+ *
+ * This field must be >= 0 and <= @ref coded_width.
+ */
+int horizontal_offset;
+/**
+ * Offset in pixels from the top edge of the grid where the actual image
+ * meant for presentation starts.
+ *
+ * This field must be >= 0 and <= @ref coded_height.
+ */
+int vertical_offset;
+
+/**
+ * Width of the final image for presentation.
+ *
+ * Must be > 0 and <= (@ref coded_width - @ref horizontal_offset).
+ * When it's not equal to (@ref coded_width - @ref horizontal_offset), the
+ * result of (@ref coded_width - width - @ref horizontal_offset) is the
+ * amount amount of pixels to be cropped from the right edge of the
+ * final image before presentation.
+ */
+int width;
+/**
+ * Height of the final image for presentation.
+ *
+ * Must be > 0 and <= (@ref coded_height - @ref vertical_offset).
+ * When it's not equal to (@ref coded_height - @ref vertical_offset), the
+ * result of (@ref coded_height - height - @ref vertical_offset) is the
+ * amount amount of pixels to be cropped from the bototm edge of the
+ * final image before presentation.
+ */
+int height;
+} AVStreamGroupTileGrid;
+
enum AVStreamGroupParamsType {
AV_STREAM_GROUP_PARAMS_NONE,
AV_STREAM_GROUP_PARAMS_IAMF_AUDIO_ELEMENT,
AV_STREAM_GROUP_PARAMS_IAMF_MIX_PRESENTATION,
+AV_STREAM_GROUP_PARAMS_TILE_GRID,
};
struct AVIAMFAudioElement;
@@ -1062,6 +1161,7 @@ typedef struct AVStreamGroup {
union {
struct AVIAMFAudioElement *iamf_audio_element;
struct AVIAMFMixPresentation *iamf_mix_prese
[FFmpeg-devel] [PATCH 6/6 v2] avformat/movenc: add support for Immersive Audio Model and Formats in ISOBMFF
Signed-off-by: James Almer
---
configure| 2 +-
libavformat/movenc.c | 323 ++-
libavformat/movenc.h | 7 +
3 files changed, 269 insertions(+), 63 deletions(-)
diff --git a/configure b/configure
index 42ba5ec502..6cdd101487 100755
--- a/configure
+++ b/configure
@@ -3547,7 +3547,7 @@ mlp_demuxer_select="mlp_parser"
mmf_muxer_select="riffenc"
mov_demuxer_select="iso_media riffdec iamf_frame_split_bsf"
mov_demuxer_suggest="zlib"
-mov_muxer_select="iso_media riffenc rtpenc_chain vp9_superframe_bsf
aac_adtstoasc_bsf ac3_parser"
+mov_muxer_select="iso_media riffenc rtpenc_chain vp9_superframe_bsf
aac_adtstoasc_bsf iamf_frame_merge_bsf ac3_parser"
mp3_demuxer_select="mpegaudio_parser"
mp3_muxer_select="mpegaudioheader"
mp4_muxer_select="mov_muxer"
diff --git a/libavformat/movenc.c b/libavformat/movenc.c
index b724bd5ebc..dfa8b6b04e 100644
--- a/libavformat/movenc.c
+++ b/libavformat/movenc.c
@@ -32,6 +32,7 @@
#include "dovi_isom.h"
#include "riff.h"
#include "avio.h"
+#include "iamf_writer.h"
#include "isom.h"
#include "av1.h"
#include "avc.h"
@@ -47,6 +48,7 @@
#include "libavcodec/raw.h"
#include "internal.h"
#include "libavutil/avstring.h"
+#include "libavutil/bprint.h"
#include "libavutil/channel_layout.h"
#include "libavutil/csp.h"
#include "libavutil/intfloat.h"
@@ -316,6 +318,32 @@ static int mov_write_sdtp_tag(AVIOContext *pb, MOVTrack
*track)
return update_size(pb, pos);
}
+static int mov_write_iacb_tag(AVFormatContext *s, AVIOContext *pb, MOVTrack
*track)
+{
+AVIOContext *dyn_bc;
+int64_t pos = avio_tell(pb);
+uint8_t *dyn_buf = NULL;
+int dyn_size;
+int ret = avio_open_dyn_buf(&dyn_bc);
+if (ret < 0)
+return ret;
+
+avio_wb32(pb, 0);
+ffio_wfourcc(pb, "iacb");
+avio_w8(pb, 1); // configurationVersion
+
+ret = ff_iamf_write_descriptors(track->iamf, dyn_bc, s);
+if (ret < 0)
+return ret;
+
+dyn_size = avio_close_dyn_buf(dyn_bc, &dyn_buf);
+ffio_write_leb(pb, dyn_size);
+avio_write(pb, dyn_buf, dyn_size);
+av_free(dyn_buf);
+
+return update_size(pb, pos);
+}
+
static int mov_write_amr_tag(AVIOContext *pb, MOVTrack *track)
{
avio_wb32(pb, 0x11); /* size */
@@ -1358,6 +1386,8 @@ static int mov_write_audio_tag(AVFormatContext *s,
AVIOContext *pb, MOVMuxContex
ret = mov_write_wave_tag(s, pb, track);
else if (track->tag == MKTAG('m','p','4','a'))
ret = mov_write_esds_tag(pb, track);
+else if (track->tag == MKTAG('i','a','m','f'))
+ret = mov_write_iacb_tag(mov->fc, pb, track);
else if (track->par->codec_id == AV_CODEC_ID_AMR_NB)
ret = mov_write_amr_tag(pb, track);
else if (track->par->codec_id == AV_CODEC_ID_AC3)
@@ -2501,7 +2531,7 @@ static int mov_write_video_tag(AVFormatContext *s,
AVIOContext *pb, MOVMuxContex
if (track->mode == MODE_AVIF) {
mov_write_ccst_tag(pb);
-if (s->nb_streams > 0 && track == &mov->tracks[1])
+if (mov->nb_streams > 0 && track == &mov->tracks[1])
mov_write_aux_tag(pb, "auxi");
}
@@ -3096,9 +3126,9 @@ static int mov_write_iloc_tag(AVIOContext *pb,
MOVMuxContext *mov, AVFormatConte
avio_wb32(pb, 0); /* Version & flags */
avio_w8(pb, (4 << 4) + 4); /* offset_size(4) and length_size(4) */
avio_w8(pb, 0); /* base_offset_size(4) and reserved(4) */
-avio_wb16(pb, s->nb_streams); /* item_count */
+avio_wb16(pb, mov->nb_streams); /* item_count */
-for (int i = 0; i < s->nb_streams; i++) {
+for (int i = 0; i < mov->nb_streams; i++) {
avio_wb16(pb, i + 1); /* item_id */
avio_wb16(pb, 0); /* data_reference_index */
avio_wb16(pb, 1); /* extent_count */
@@ -3117,9 +3147,9 @@ static int mov_write_iinf_tag(AVIOContext *pb,
MOVMuxContext *mov, AVFormatConte
avio_wb32(pb, 0); /* size */
ffio_wfourcc(pb, "iinf");
avio_wb32(pb, 0); /* Version & flags */
-avio_wb16(pb, s->nb_streams); /* entry_count */
+avio_wb16(pb, mov->nb_streams); /* entry_count */
-for (int i = 0; i < s->nb_streams; i++) {
+for (int i = 0; i < mov->nb_streams; i++) {
int64_t infe_pos = avio_tell(pb);
avio_wb32(pb, 0); /* size */
ffio_wfourcc(pb, "infe");
@@ -3188,7 +3218,7 @@ static int mov_write_ipco_tag(AVIOContext *pb,
MOVMuxContext *mov, AVFormatConte
int64_t pos = avio_tell(pb);
avio_wb32(pb, 0); /* size */
ffio_wfourcc(pb, "ipco");
-for (int i = 0; i < s->nb_streams; i++) {
+for (int i = 0; i < mov->nb_streams; i++) {
mov_write_ispe_tag(pb, mov, s, i);
mov_write_pixi_tag(pb, mov, s, i);
mov_write_av1c_tag(pb, &mov->tracks[i]);
@@ -3206,9 +3236,9 @@ static int mov_write_ipma_tag(AVIOContext *pb,
MOVMuxContext *mov, AVFormatConte
avio_wb32(pb, 0); /* size */
ffio_wfourcc(pb, "ipma");
avio_wb32(pb, 0); /* Version & flags */
-avio_wb32(pb, s->nb_streams); /* entry
[FFmpeg-devel] [PATCH 5/6 v2] avcodec: add an Immersive Audio Model and Formats frame merge bsf
Signed-off-by: James Almer
---
doc/bitstream_filters.texi| 14 ++
libavcodec/bitstream_filters.c| 1 +
libavcodec/bsf/Makefile | 1 +
libavcodec/bsf/iamf_frame_merge_bsf.c | 228 ++
libavcodec/leb.h | 22 +++
5 files changed, 266 insertions(+)
create mode 100644 libavcodec/bsf/iamf_frame_merge_bsf.c
diff --git a/doc/bitstream_filters.texi b/doc/bitstream_filters.texi
index 7e0cfa3e26..879182f00f 100644
--- a/doc/bitstream_filters.texi
+++ b/doc/bitstream_filters.texi
@@ -478,6 +478,20 @@ are coded.
Lowest stream index value to set in output packets
@end table
+@section iamf_frame_merge
+
+Encapsulate audio data packets from different streams and merge them
+into a single Audio Frame OBUs.
+
+@table @option
+@item index_mapping
+A :-separated list of stream_index=audio_substream_id entries to set
+stream id in output Audio Frame OBUs
+
+@item out_index
+Stream index to in output packets
+@end table
+
@section imxdump
Modifies the bitstream to fit in MOV and to be usable by the Final Cut
diff --git a/libavcodec/bitstream_filters.c b/libavcodec/bitstream_filters.c
index 476331ec8a..61c090a2f1 100644
--- a/libavcodec/bitstream_filters.c
+++ b/libavcodec/bitstream_filters.c
@@ -42,6 +42,7 @@ extern const FFBitStreamFilter ff_h264_redundant_pps_bsf;
extern const FFBitStreamFilter ff_hapqa_extract_bsf;
extern const FFBitStreamFilter ff_hevc_metadata_bsf;
extern const FFBitStreamFilter ff_hevc_mp4toannexb_bsf;
+extern const FFBitStreamFilter ff_iamf_frame_merge_bsf;
extern const FFBitStreamFilter ff_iamf_frame_split_bsf;
extern const FFBitStreamFilter ff_imx_dump_header_bsf;
extern const FFBitStreamFilter ff_media100_to_mjpegb_bsf;
diff --git a/libavcodec/bsf/Makefile b/libavcodec/bsf/Makefile
index cb23428f4a..ff024d47f1 100644
--- a/libavcodec/bsf/Makefile
+++ b/libavcodec/bsf/Makefile
@@ -20,6 +20,7 @@ OBJS-$(CONFIG_H264_REDUNDANT_PPS_BSF) +=
bsf/h264_redundant_pps.o
OBJS-$(CONFIG_HAPQA_EXTRACT_BSF) += bsf/hapqa_extract.o
OBJS-$(CONFIG_HEVC_METADATA_BSF) += bsf/h265_metadata.o
OBJS-$(CONFIG_HEVC_MP4TOANNEXB_BSF) += bsf/hevc_mp4toannexb.o
+OBJS-$(CONFIG_IAMF_FRAME_MERGE_BSF) += bsf/iamf_frame_merge_bsf.o
OBJS-$(CONFIG_IAMF_FRAME_SPLIT_BSF) += bsf/iamf_frame_split_bsf.o
OBJS-$(CONFIG_IMX_DUMP_HEADER_BSF)+= bsf/imx_dump_header.o
OBJS-$(CONFIG_MEDIA100_TO_MJPEGB_BSF) += bsf/media100_to_mjpegb.o
diff --git a/libavcodec/bsf/iamf_frame_merge_bsf.c
b/libavcodec/bsf/iamf_frame_merge_bsf.c
new file mode 100644
index 00..98f37be653
--- /dev/null
+++ b/libavcodec/bsf/iamf_frame_merge_bsf.c
@@ -0,0 +1,228 @@
+/*
+ * Copyright (c) 2024 James Almer
+ *
+ * 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
+#include
+
+#include "libavutil/dict.h"
+#include "libavutil/fifo.h"
+#include "libavutil/opt.h"
+#include "libavformat/iamf.h"
+#include "bsf.h"
+#include "bsf_internal.h"
+#include "bytestream.h"
+#include "get_bits.h"
+#include "leb.h"
+#include "put_bits.h"
+
+typedef struct IAMFMergeContext {
+AVClass *class;
+
+AVFifo *fifo;
+
+// AVOptions
+AVDictionary *index_mapping;
+int stream_count;
+int out_index;
+} IAMFMergeContext;
+
+static int find_id_from_idx(AVBSFContext *ctx, int idx)
+{
+IAMFMergeContext *const c = ctx->priv_data;
+const AVDictionaryEntry *e = NULL;
+
+while (e = av_dict_iterate(c->index_mapping, e)) {
+char *endptr = NULL;
+int id, map_idx = strtol(e->key, &endptr, 0);
+if (!endptr || *endptr)
+return AVERROR_INVALIDDATA;
+endptr = NULL;
+id = strtol(e->value, &endptr, 0);
+if (!endptr || *endptr)
+return AVERROR_INVALIDDATA;
+if (map_idx == idx)
+return id;
+}
+
+av_log(ctx, AV_LOG_ERROR, "Invalid stream idx %d\n", idx);
+return AVERROR_INVALIDDATA;
+}
+
+static int iamf_frame_merge_filter(AVBSFContext *ctx, AVPacket *out)
+{
+IAMFMergeContext *const c = ctx->priv_data;
+AVPacket *pkt;
+int ret;
+
+while (av_fifo_can_write(c->fifo)) {
+ret = ff_bsf_get_packet(ctx, &pkt);
+if (ret < 0)
+return ret;
+av_fifo_write(c->fifo,
[FFmpeg-devel] [PATCH 4/6 v3] avformat/mov: add support for Immersive Audio Model and Formats in ISOBMFF
Signed-off-by: James Almer
---
configure| 2 +-
libavformat/Makefile | 3 +-
libavformat/isom.h | 6 +
libavformat/mov.c| 283 ---
4 files changed, 276 insertions(+), 18 deletions(-)
diff --git a/configure b/configure
index 68f675a4bc..42ba5ec502 100755
--- a/configure
+++ b/configure
@@ -3545,7 +3545,7 @@ matroska_demuxer_suggest="bzlib zlib"
matroska_muxer_select="mpeg4audio riffenc aac_adtstoasc_bsf
pgs_frame_merge_bsf vp9_superframe_bsf"
mlp_demuxer_select="mlp_parser"
mmf_muxer_select="riffenc"
-mov_demuxer_select="iso_media riffdec"
+mov_demuxer_select="iso_media riffdec iamf_frame_split_bsf"
mov_demuxer_suggest="zlib"
mov_muxer_select="iso_media riffenc rtpenc_chain vp9_superframe_bsf
aac_adtstoasc_bsf ac3_parser"
mp3_demuxer_select="mpegaudio_parser"
diff --git a/libavformat/Makefile b/libavformat/Makefile
index 05b9b8a115..4131279e69 100644
--- a/libavformat/Makefile
+++ b/libavformat/Makefile
@@ -364,7 +364,8 @@ OBJS-$(CONFIG_MMF_MUXER) += mmf.o rawenc.o
OBJS-$(CONFIG_MODS_DEMUXER) += mods.o
OBJS-$(CONFIG_MOFLEX_DEMUXER)+= moflex.o
OBJS-$(CONFIG_MOV_DEMUXER) += mov.o mov_chan.o mov_esds.o \
-qtpalette.o replaygain.o
dovi_isom.o
+qtpalette.o replaygain.o
dovi_isom.o \
+iamf.o
OBJS-$(CONFIG_MOV_MUXER) += movenc.o av1.o avc.o hevc.o vvc.o
vpcc.o \
movenchint.o mov_chan.o rtp.o \
movenccenc.o movenc_ttml.o
rawutils.o \
diff --git a/libavformat/isom.h b/libavformat/isom.h
index a4925b3b08..9f202b3d73 100644
--- a/libavformat/isom.h
+++ b/libavformat/isom.h
@@ -33,6 +33,7 @@
#include "libavutil/stereo3d.h"
#include "avio.h"
+#include "iamf.h"
#include "internal.h"
#include "dv.h"
@@ -167,6 +168,7 @@ typedef struct MOVStreamContext {
AVIOContext *pb;
int refcount;
int pb_is_copied;
+int id; ///< AVStream id
int ffindex; ///< AVStream index
int next_chunk;
unsigned int chunk_count;
@@ -261,6 +263,10 @@ typedef struct MOVStreamContext {
AVEncryptionInfo *default_encrypted_sample;
MOVEncryptionIndex *encryption_index;
} cenc;
+
+IAMFContext *iamf;
+uint8_t *iamf_descriptors;
+int iamf_descriptors_size;
} MOVStreamContext;
typedef struct HEIFItem {
diff --git a/libavformat/mov.c b/libavformat/mov.c
index 555c72dc79..981a48e074 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -58,6 +58,7 @@
#include "internal.h"
#include "avio_internal.h"
#include "demux.h"
+#include "iamf_parse.h"
#include "dovi_isom.h"
#include "riff.h"
#include "isom.h"
@@ -211,6 +212,7 @@ static int mov_read_covr(MOVContext *c, AVIOContext *pb,
int type, int len)
}
st = c->fc->streams[c->fc->nb_streams - 1];
st->priv_data = sc;
+sc->id = st->id;
sc->refcount = 1;
if (st->attached_pic.size >= 8 && id != AV_CODEC_ID_BMP) {
@@ -835,6 +837,178 @@ static int mov_read_dac3(MOVContext *c, AVIOContext *pb,
MOVAtom atom)
return 0;
}
+static int mov_read_iacb(MOVContext *c, AVIOContext *pb, MOVAtom atom)
+{
+AVStream *st;
+MOVStreamContext *sc;
+FFIOContext b;
+AVIOContext *descriptor_pb;
+AVDictionary *metadata;
+IAMFContext *iamf;
+char args[32];
+int64_t start_time, duration;
+unsigned size;
+int nb_frames, disposition;
+int version, ret;
+
+if (atom.size < 5)
+return AVERROR_INVALIDDATA;
+
+if (c->fc->nb_streams < 1)
+return 0;
+
+version = avio_r8(pb);
+if (version != 1) {
+av_log(c->fc, AV_LOG_ERROR, "%s configurationVersion %d",
+ version < 1 ? "invalid" : "unsupported", version);
+return AVERROR_INVALIDDATA;
+}
+
+size = ffio_read_leb(pb);
+if (!size)
+return AVERROR_INVALIDDATA;
+
+st = c->fc->streams[c->fc->nb_streams - 1];
+sc = st->priv_data;
+
+iamf = sc->iamf = av_mallocz(sizeof(*iamf));
+if (!iamf)
+return AVERROR(ENOMEM);
+
+sc->iamf_descriptors = av_malloc(size);
+if (!sc->iamf_descriptors)
+return AVERROR(ENOMEM);
+
+sc->iamf_descriptors_size = size;
+ret = avio_read(pb, sc->iamf_descriptors, size);
+if (ret != size)
+return ret < 0 ? ret : AVERROR_INVALIDDATA;
+
+ffio_init_read_context(&b, sc->iamf_descriptors, size);
+descriptor_pb = &b.pub;
+
+ret = ff_iamfdec_read_descriptors(iamf, descriptor_pb, size, c->fc);
+if (ret < 0)
+return ret;
+
+metadata = st->metadata;
+st->metadata = NULL;
+start_time = st->start_time;
+nb_frames = st->nb_frames;
+duration = st->duration;
+disposition = st->disposition;
+
+for (int i = 0; i < iamf->nb_audio_elements; i++) {
+IAMF
[FFmpeg-devel] [PATCH 3/6 v3] avformat/mov: make MOVStreamContext refcounted
Signed-off-by: James Almer
---
libavformat/isom.h | 1 +
libavformat/mov.c | 105 +
2 files changed, 59 insertions(+), 47 deletions(-)
diff --git a/libavformat/isom.h b/libavformat/isom.h
index 2cf456fee1..a4925b3b08 100644
--- a/libavformat/isom.h
+++ b/libavformat/isom.h
@@ -165,6 +165,7 @@ typedef struct MOVIndexRange {
typedef struct MOVStreamContext {
AVIOContext *pb;
+int refcount;
int pb_is_copied;
int ffindex; ///< AVStream index
int next_chunk;
diff --git a/libavformat/mov.c b/libavformat/mov.c
index cf931d4594..555c72dc79 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -211,6 +211,7 @@ static int mov_read_covr(MOVContext *c, AVIOContext *pb,
int type, int len)
}
st = c->fc->streams[c->fc->nb_streams - 1];
st->priv_data = sc;
+sc->refcount = 1;
if (st->attached_pic.size >= 8 && id != AV_CODEC_ID_BMP) {
if (AV_RB64(st->attached_pic.data) == 0x89504e470d0a1a0a) {
@@ -4654,6 +4655,7 @@ static int mov_read_trak(MOVContext *c, AVIOContext *pb,
MOVAtom atom)
st->codecpar->codec_type = AVMEDIA_TYPE_DATA;
sc->ffindex = st->index;
c->trak_index = st->index;
+sc->refcount = 1;
if ((ret = mov_read_default(c, pb, atom)) < 0)
return ret;
@@ -4941,6 +4943,7 @@ static int heif_add_stream(MOVContext *c, HEIFItem *item)
sc = st->priv_data;
sc->pb = c->fc->pb;
sc->pb_is_copied = 1;
+sc->refcount = 1;
// Populate the necessary fields used by mov_build_index.
sc->stsc_count = 1;
@@ -8587,6 +8590,60 @@ static void mov_free_encryption_index(MOVEncryptionIndex
**index) {
av_freep(index);
}
+static void mov_free_stream_context(AVFormatContext *s, AVStream *st)
+{
+MOVStreamContext *sc = st->priv_data;
+
+if (!sc || --sc->refcount) {
+st->priv_data = NULL;
+return;
+}
+
+av_freep(&sc->ctts_data);
+for (int i = 0; i < sc->drefs_count; i++) {
+av_freep(&sc->drefs[i].path);
+av_freep(&sc->drefs[i].dir);
+}
+av_freep(&sc->drefs);
+
+sc->drefs_count = 0;
+
+if (!sc->pb_is_copied)
+ff_format_io_close(s, &sc->pb);
+
+sc->pb = NULL;
+av_freep(&sc->chunk_offsets);
+av_freep(&sc->stsc_data);
+av_freep(&sc->sample_sizes);
+av_freep(&sc->keyframes);
+av_freep(&sc->stts_data);
+av_freep(&sc->sdtp_data);
+av_freep(&sc->stps_data);
+av_freep(&sc->elst_data);
+av_freep(&sc->rap_group);
+av_freep(&sc->sync_group);
+av_freep(&sc->sgpd_sync);
+av_freep(&sc->sample_offsets);
+av_freep(&sc->open_key_samples);
+av_freep(&sc->display_matrix);
+av_freep(&sc->index_ranges);
+
+if (sc->extradata)
+for (int i = 0; i < sc->stsd_count; i++)
+av_free(sc->extradata[i]);
+av_freep(&sc->extradata);
+av_freep(&sc->extradata_size);
+
+mov_free_encryption_index(&sc->cenc.encryption_index);
+av_encryption_info_free(sc->cenc.default_encrypted_sample);
+av_aes_ctr_free(sc->cenc.aes_ctr);
+
+av_freep(&sc->stereo3d);
+av_freep(&sc->spherical);
+av_freep(&sc->mastering);
+av_freep(&sc->coll);
+}
+
static int mov_read_close(AVFormatContext *s)
{
MOVContext *mov = s->priv_data;
@@ -8594,54 +8651,8 @@ static int mov_read_close(AVFormatContext *s)
for (i = 0; i < s->nb_streams; i++) {
AVStream *st = s->streams[i];
-MOVStreamContext *sc = st->priv_data;
-
-if (!sc)
-continue;
-
-av_freep(&sc->ctts_data);
-for (j = 0; j < sc->drefs_count; j++) {
-av_freep(&sc->drefs[j].path);
-av_freep(&sc->drefs[j].dir);
-}
-av_freep(&sc->drefs);
-sc->drefs_count = 0;
-
-if (!sc->pb_is_copied)
-ff_format_io_close(s, &sc->pb);
-
-sc->pb = NULL;
-av_freep(&sc->chunk_offsets);
-av_freep(&sc->stsc_data);
-av_freep(&sc->sample_sizes);
-av_freep(&sc->keyframes);
-av_freep(&sc->stts_data);
-av_freep(&sc->sdtp_data);
-av_freep(&sc->stps_data);
-av_freep(&sc->elst_data);
-av_freep(&sc->rap_group);
-av_freep(&sc->sync_group);
-av_freep(&sc->sgpd_sync);
-av_freep(&sc->sample_offsets);
-av_freep(&sc->open_key_samples);
-av_freep(&sc->display_matrix);
-av_freep(&sc->index_ranges);
-
-if (sc->extradata)
-for (j = 0; j < sc->stsd_count; j++)
-av_free(sc->extradata[j]);
-av_freep(&sc->extradata);
-av_freep(&sc->extradata_size);
-
-mov_free_encryption_index(&sc->cenc.encryption_index);
-av_encryption_info_free(sc->cenc.default_encrypted_sample);
-av_aes_ctr_free(sc->cenc.aes_ctr);
-
-av_freep(&sc->stereo3d);
-av_freep(&sc->spherical);
-av_freep(&sc->mastering);
-av_freep(&sc->coll);
+mov_free_stream_context(s, st);
}
[FFmpeg-devel] [PATCH 2/6 v3] avformat/demux: support inserting bitstream filters in demuxing scenarios
Packets will be passed to the bsf immediately after being generated by a
demuxer, and no further data will be read from the input until all packets
have been returned by the bsf.
Signed-off-by: James Almer
---
libavformat/avformat.c | 47
libavformat/demux.c| 162 ++---
libavformat/internal.h | 13 +++-
libavformat/mux.c | 43 ---
libavformat/mux.h | 11 ---
libavformat/rawenc.c | 1 +
6 files changed, 181 insertions(+), 96 deletions(-)
diff --git a/libavformat/avformat.c b/libavformat/avformat.c
index 8e8c6fbe55..0e22d47c8b 100644
--- a/libavformat/avformat.c
+++ b/libavformat/avformat.c
@@ -931,3 +931,50 @@ FF_ENABLE_DEPRECATION_WARNINGS
*pb = NULL;
return ret;
}
+
+int ff_stream_add_bitstream_filter(AVStream *st, const char *name, const char
*args)
+{
+int ret;
+const AVBitStreamFilter *bsf;
+FFStream *const sti = ffstream(st);
+AVBSFContext *bsfc;
+
+av_assert0(!sti->bsfc);
+
+if (name) {
+bsf = av_bsf_get_by_name(name);
+if (!bsf) {
+av_log(NULL, AV_LOG_ERROR, "Unknown bitstream filter '%s'\n",
name);
+return AVERROR_BSF_NOT_FOUND;
+}
+ret = av_bsf_alloc(bsf, &bsfc);
+} else
+ret = av_bsf_get_null_filter(&bsfc);
+if (ret < 0)
+return ret;
+
+bsfc->time_base_in = st->time_base;
+if ((ret = avcodec_parameters_copy(bsfc->par_in, st->codecpar)) < 0) {
+av_bsf_free(&bsfc);
+return ret;
+}
+
+if (args && bsfc->filter->priv_class) {
+if ((ret = av_set_options_string(bsfc->priv_data, args, "=", ":")) <
0) {
+av_bsf_free(&bsfc);
+return ret;
+}
+}
+
+if ((ret = av_bsf_init(bsfc)) < 0) {
+av_bsf_free(&bsfc);
+return ret;
+}
+
+sti->bsfc = bsfc;
+
+av_log(NULL, AV_LOG_VERBOSE,
+ "Automatically inserted bitstream filter '%s'; args='%s'\n",
+ name, args ? args : "");
+return 1;
+}
diff --git a/libavformat/demux.c b/libavformat/demux.c
index 6f640b92b1..fb9bf9e4ac 100644
--- a/libavformat/demux.c
+++ b/libavformat/demux.c
@@ -540,6 +540,109 @@ static int update_wrap_reference(AVFormatContext *s,
AVStream *st, int stream_in
return 1;
}
+static void update_timestamps(AVFormatContext *s, AVStream *st, AVPacket *pkt)
+{
+FFStream *const sti = ffstream(st);
+
+if (update_wrap_reference(s, st, pkt->stream_index, pkt) &&
sti->pts_wrap_behavior == AV_PTS_WRAP_SUB_OFFSET) {
+// correct first time stamps to negative values
+if (!is_relative(sti->first_dts))
+sti->first_dts = wrap_timestamp(st, sti->first_dts);
+if (!is_relative(st->start_time))
+st->start_time = wrap_timestamp(st, st->start_time);
+if (!is_relative(sti->cur_dts))
+sti->cur_dts = wrap_timestamp(st, sti->cur_dts);
+}
+
+pkt->dts = wrap_timestamp(st, pkt->dts);
+pkt->pts = wrap_timestamp(st, pkt->pts);
+
+force_codec_ids(s, st);
+
+/* TODO: audio: time filter; video: frame reordering (pts != dts) */
+if (s->use_wallclock_as_timestamps)
+pkt->dts = pkt->pts = av_rescale_q(av_gettime(), AV_TIME_BASE_Q,
st->time_base);
+}
+
+static int filter_packet(AVFormatContext *s, AVStream *st, AVPacket *pkt)
+{
+FFFormatContext *const si = ffformatcontext(s);
+FFStream *const sti = ffstream(st);
+const AVPacket *pkt1;
+int err;
+
+if (!sti->bsfc) {
+const PacketListEntry *pktl = si->raw_packet_buffer.head;
+if (AVPACKET_IS_EMPTY(pkt))
+return 0;
+
+update_timestamps(s, st, pkt);
+
+if (!pktl && sti->request_probe <= 0)
+return 0;
+
+err = avpriv_packet_list_put(&si->raw_packet_buffer, pkt, NULL, 0);
+if (err < 0) {
+av_packet_unref(pkt);
+return err;
+}
+
+pkt1 = &si->raw_packet_buffer.tail->pkt;
+si->raw_packet_buffer_size += pkt1->size;
+
+if (sti->request_probe <= 0)
+return 0;
+
+return probe_codec(s, s->streams[pkt1->stream_index], pkt1);
+}
+
+err = av_bsf_send_packet(sti->bsfc, pkt);
+if (err < 0) {
+av_log(s, AV_LOG_ERROR,
+"Failed to send packet to filter %s for stream %d\n",
+sti->bsfc->filter->name, st->index);
+return err;
+}
+
+do {
+AVStream *out_st;
+FFStream *out_sti;
+
+err = av_bsf_receive_packet(sti->bsfc, pkt);
+if (err < 0) {
+if (err == AVERROR(EAGAIN) || err == AVERROR_EOF)
+return 0;
+av_log(s, AV_LOG_ERROR, "Error applying bitstream filters to an
output "
+ "packet for stream #%d: %s\n", st->index, av_err2str(err));
+if (!(s->error_recognition & AV_EF_EXPLODE) && err !=
AVERROR(ENOMEM))
+continue;
+return err;
+}
+out_st = s->stre
[FFmpeg-devel] [PATCH 1/6 v3] avcodec: add an Immersive Audio Model and Formats frame split bsf
Signed-off-by: James Almer
---
doc/bitstream_filters.texi| 13 +
libavcodec/bitstream_filters.c| 1 +
libavcodec/bsf/Makefile | 1 +
libavcodec/bsf/iamf_frame_split_bsf.c | 825 ++
4 files changed, 840 insertions(+)
create mode 100644 libavcodec/bsf/iamf_frame_split_bsf.c
diff --git a/doc/bitstream_filters.texi b/doc/bitstream_filters.texi
index dc4f85bac0..7e0cfa3e26 100644
--- a/doc/bitstream_filters.texi
+++ b/doc/bitstream_filters.texi
@@ -465,6 +465,19 @@ Please note that this filter is auto-inserted for MPEG-TS
(muxer
@code{mpegts}) and raw HEVC/H.265 (muxer @code{h265} or
@code{hevc}) output formats.
+@section iamf_frame_split
+
+Split a packet containing one or more Audio Frame OBUs into several
+packets each containing the respective extracted raw audio data from
+every Audio Frame.
+Stream index in output packets will be set based on the order the OBUs
+are coded.
+
+@table @option
+@item first_index
+Lowest stream index value to set in output packets
+@end table
+
@section imxdump
Modifies the bitstream to fit in MOV and to be usable by the Final Cut
diff --git a/libavcodec/bitstream_filters.c b/libavcodec/bitstream_filters.c
index 1e9a676a3d..476331ec8a 100644
--- a/libavcodec/bitstream_filters.c
+++ b/libavcodec/bitstream_filters.c
@@ -42,6 +42,7 @@ extern const FFBitStreamFilter ff_h264_redundant_pps_bsf;
extern const FFBitStreamFilter ff_hapqa_extract_bsf;
extern const FFBitStreamFilter ff_hevc_metadata_bsf;
extern const FFBitStreamFilter ff_hevc_mp4toannexb_bsf;
+extern const FFBitStreamFilter ff_iamf_frame_split_bsf;
extern const FFBitStreamFilter ff_imx_dump_header_bsf;
extern const FFBitStreamFilter ff_media100_to_mjpegb_bsf;
extern const FFBitStreamFilter ff_mjpeg2jpeg_bsf;
diff --git a/libavcodec/bsf/Makefile b/libavcodec/bsf/Makefile
index 7831b0f2aa..cb23428f4a 100644
--- a/libavcodec/bsf/Makefile
+++ b/libavcodec/bsf/Makefile
@@ -20,6 +20,7 @@ OBJS-$(CONFIG_H264_REDUNDANT_PPS_BSF) +=
bsf/h264_redundant_pps.o
OBJS-$(CONFIG_HAPQA_EXTRACT_BSF) += bsf/hapqa_extract.o
OBJS-$(CONFIG_HEVC_METADATA_BSF) += bsf/h265_metadata.o
OBJS-$(CONFIG_HEVC_MP4TOANNEXB_BSF) += bsf/hevc_mp4toannexb.o
+OBJS-$(CONFIG_IAMF_FRAME_SPLIT_BSF) += bsf/iamf_frame_split_bsf.o
OBJS-$(CONFIG_IMX_DUMP_HEADER_BSF)+= bsf/imx_dump_header.o
OBJS-$(CONFIG_MEDIA100_TO_MJPEGB_BSF) += bsf/media100_to_mjpegb.o
OBJS-$(CONFIG_MJPEG2JPEG_BSF) += bsf/mjpeg2jpeg.o
diff --git a/libavcodec/bsf/iamf_frame_split_bsf.c
b/libavcodec/bsf/iamf_frame_split_bsf.c
new file mode 100644
index 00..3e416e1ca1
--- /dev/null
+++ b/libavcodec/bsf/iamf_frame_split_bsf.c
@@ -0,0 +1,825 @@
+/*
+ * Copyright (c) 2023 James Almer
+ *
+ * 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
+#include
+
+#include "libavutil/dict.h"
+#include "libavutil/opt.h"
+#include "libavformat/iamf.h"
+#include "bsf.h"
+#include "bsf_internal.h"
+#include "get_bits.h"
+#include "leb.h"
+
+typedef struct ParamDefinition {
+AVIAMFParamDefinition *param;
+size_t param_size;
+int mode;
+int recon_gain_present_bitmask;
+} ParamDefinition;
+
+typedef struct IAMFSplitContext {
+AVClass *class;
+AVPacket *buffer_pkt;
+
+ParamDefinition *param_definitions;
+unsigned int nb_param_definitions;
+
+unsigned int *ids;
+int nb_ids;
+
+// AVOptions
+int first_index;
+
+// Packet side data
+AVIAMFParamDefinition *mix;
+size_t mix_size;
+AVIAMFParamDefinition *demix;
+size_t demix_size;
+AVIAMFParamDefinition *recon;
+size_t recon_size;
+} IAMFSplitContext;
+
+static int param_parse(AVBSFContext *ctx, GetBitContext *gb,
+ unsigned int type,
+ ParamDefinition **out)
+{
+IAMFSplitContext *const c = ctx->priv_data;
+ParamDefinition *param_definition = NULL;
+AVIAMFParamDefinition *param;
+unsigned int parameter_id, parameter_rate, mode;
+unsigned int duration = 0, constant_subblock_duration = 0, nb_subblocks =
0;
+size_t param_size;
+
+parameter_id = get_leb(gb);
+
+for (int i = 0; i < c->nb_param_definitions; i++)
+if (c->param_definitions[i].param->parame
Re: [FFmpeg-devel] Sovereign Tech Fund
> I take that to mean that SPI has been involved with those discussions for months in a private and closed process Not really, however STF did ask for a meeting with SPI concerning the possibility to sponsor FFmpeg on January 18th (so roughly two weeks ago). To make clear, the request was on the 15th, the actual meeting on the 18th. There was some back-and-forth between both, Thilo and Michael commented on some specifics as STF or SPI asked, and we concluded SPI could indeed receive a sponsorship from STF on behalf of FFmpeg project on January 23th. Not long after, STF confirmed to SPI that it would be discussed in Feb 14th internally and that FFmpeg should send a Scope of Work by the 12th in order to confirm the sponsorship. That request was sent on Jan 25th. I'm not sure when this information was sent to this mailing list, but Michael and Thilo were informed on the same day. That's what happened recently on the SPI side in any Earthly time metric. But I should mention that in July 2023, Stefano and our contractors reached out to me and the vice president asking for, among other things, the Master Service Agreement which SPI uses and some general and everyday discussions about SPI policies regarding the payment of individual contractors/developers. I believe they also mentioned the possibility of getting a sponsorship from STF in the future, but discussions were centered on how SPI could pay for individual developers, which is why I didn't remember about this until I searched for it today. I guess you could say SPI was "aware" of the possibility since then. The first and last message from this message chain were on July 11th and July 23rd respectively, although I assume they made questions to non-board members before reaching out for SPI's VP and me. There was no further contact with SPI about that between July 24th and January 15th. Miscommunication happens. Do not assume malice, if you need any further information from SPI just reach out, we'll be happy to provide. > misrepresent any challenge to SPI proposed *process* as an attempt to reject the idea of STF sponsorship, under the convenient pretext that there is not enough time. Just in case, it was STF who asked for a Scope of Work to be presented by February 12th. I'm pretty sure it is possible to ask them about the possibility of postponing the topic for their next meeting (which I assume to be in March) ─ STF may decline, though, and it might not be possible to turn back on this decision or postpone further. I'm not STF's contact, it is someone from FFmpeg who is, so they'll need to do this. (also why I didn't mention that earlier). SPI is not conducting these discussions, after all. That's something you have to decide by yourselves. > This is ostensibly being to ignore all the objections that were already brought in October [...] SPI is not aware of any such objections. > But that will take place without the consent of the GA I'm not sure SPI would accept the sponsorship from STF without the consent of the GA, although we do expect to hear from Stefano the position FFmpeg is going to take. Which does mean that if STF sends funds to SPI but Stefano says he doesn't know what they're about, SPI will return the money post-haste (and will be less willing to receive potentially unwanted money later, as returning funds is not without costs). > I have to infer that Thilo, Michael and SPI already knew of the STF plan and concealed that key piece of contextual information back then. SPI usually doesn't *do* anything until it is asked to. We were aware in July 2023 that FFmpeg was considering asking STF about a sponsorship, although we weren't informed of whatever happened until STF asked for a meeting with us on January 15th. (Some of the SPI Board members even presumed FFmpeg had given up and forgotten altogether). > I can only agree with Anton that this looks like an attempt to strongarm the community. SPI is not trying to strongarm you into anything. Unless you try to do something illegal and we're required by law to intervene, I guess, which was discussed (e.g. "can the GA refuse to pay an invoice which is due?", which I made clear SPI would pay the invoice despite the objection, because the law requires it to be done). SPI as a rule of thumb does not interfere in its projects' management and decisions. If you want to give up on the sponsorship we'll honor the decision, if you want the sponsorship in different terms we can discuss if it's possible (and if it's not, SPI will not accept, because as I said earlier SPI is bound by the law). And if you want for more time to discuss, you should be asking that to STF, I can only help you as an agenda UNDER THE PRETENSE that FFmpeg is actually interested in meeting with STF request. If FFmpeg is not interested in attending STF's request of delivering them a Scope of Work by February 12th, I'll stop posting agenda-like reminders or suggestions. Att., -- Jonatas L. Nogueira (“jesusalva”) Boar
[FFmpeg-devel] [PATCH] configure: fix compilation with glslang 14
The configure check already had fallback for the previous version
of glslang, which had different requirements for flags.
This commit simply moves the flags needed for glslang 13 to the
fallback, while first trying to use new flags for glslang 14.
This drops support for ~3 year old glslang versions, which
I'm not sure had the complete C API we're using anyway.
Patch attached.
>From 2c33a103832901579cc90a4da2d6eb17e233d9da Mon Sep 17 00:00:00 2001
From: Lynne
Date: Wed, 31 Jan 2024 17:28:56 +0100
Subject: [PATCH] configure: fix compilation with glslang 14
The configure check already had fallback for the previous version
of glslang, which had different requirements for flags.
This commit simply moves the flags needed for glslang 13 to the
fallback, while first trying to use new flags for glslang 14.
This drops support for ~3 year old glslang versions, which
I'm not sure had the complete C API we're using anyway.
---
configure | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/configure b/configure
index 68f675a4bc..421d182c97 100755
--- a/configure
+++ b/configure
@@ -6772,11 +6772,11 @@ enabled libfreetype && require_pkg_config libfreetype freetype2 "ft2build.
enabled libfribidi&& require_pkg_config libfribidi fribidi fribidi.h fribidi_version_info
enabled libharfbuzz && require_pkg_config libharfbuzz harfbuzz hb.h hb_buffer_create
enabled libglslang && { check_lib spirv_compiler glslang/Include/glslang_c_interface.h glslang_initialize_process \
--lglslang -lMachineIndependent -lOSDependent -lHLSL -lOGLCompiler -lGenericCodeGen \
+-lglslang -lMachineIndependent -lGenericCodeGen \
-lSPVRemapper -lSPIRV -lSPIRV-Tools-opt -lSPIRV-Tools -lpthread -lstdc++ -lm ||
require spirv_compiler glslang/Include/glslang_c_interface.h glslang_initialize_process \
--lglslang -lOSDependent -lHLSL -lOGLCompiler \
--lSPVRemapper -lSPIRV -lSPIRV-Tools-opt -lSPIRV-Tools -lpthread -lstdc++ -lm; }
+-lglslang -lMachineIndependent -lOSDependent -lHLSL -lOGLCompiler -lGenericCodeGen \
+-lSPVRemapper -lSPIRV -lSPIRV-Tools-opt -lSPIRV-Tools -lpthread -lstdc++ -lm ; }
enabled libgme&& { check_pkg_config libgme libgme gme/gme.h gme_new_emu ||
require libgme gme/gme.h gme_new_emu -lgme -lstdc++; }
enabled libgsm&& { for gsm_hdr in "gsm.h" "gsm/gsm.h"; do
--
2.43.0.381.gb435a96ce8
___
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/4] lavc/rv34dsp: R-V V rv34_inv_transform_dc
Hi, I think this breaks the build for RV32, and it lacks checks for the vector length. Also fractional multipler should never be smaller than the ratio of the specified element size to the largest element size used in the function. Here it is largelly inconsequential, but for instance "e32, mf4" and "e64, mf2" are invalid. -- 雷米‧德尼-库尔蒙 http://www.remlab.net/ ___ 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] libavcodec: add tune_content option also for VP8.
This exposes VP8E_SET_SCREEN_CONTENT_MODE option from libvpx.
Changes since v1:
- Put the new param initialzation in the right place,
- Account for cases when the encoder's output is queued up.
Co-authored-by: Erik Språng
Signed-off-by: Dariusz Marcinkiewicz
---
doc/encoders.texi | 7 --
libavcodec/libvpxenc.c | 56 ++
2 files changed, 56 insertions(+), 7 deletions(-)
diff --git a/doc/encoders.texi b/doc/encoders.texi
index c9fe6d6143..2a9b38f62a 100644
--- a/doc/encoders.texi
+++ b/doc/encoders.texi
@@ -2186,6 +2186,11 @@ Enable error resiliency features.
Increase sharpness at the expense of lower PSNR.
The valid range is [0, 7].
+@item tune-content
+Set content type.
+For VP8: default (0), screen (1), screen with aggressive rate control (2).
+For VP9: default (0), screen (1), film (2).
+
@item ts-parameters
Sets the temporal scalability configuration using a :-separated list of
key=value pairs. For example, to specify temporal scalability parameters
@@ -2268,8 +2273,6 @@ colorspaces:
@end table
@item row-mt @var{boolean}
Enable row based multi-threading.
-@item tune-content
-Set content type: default (0), screen (1), film (2).
@item corpus-complexity
Corpus VBR mode is a variant of standard VBR where the complexity distribution
midpoint is passed in rather than calculated for a specific clip or chunk.
diff --git a/libavcodec/libvpxenc.c b/libavcodec/libvpxenc.c
index 80988a2608..c73c92d49b 100644
--- a/libavcodec/libvpxenc.c
+++ b/libavcodec/libvpxenc.c
@@ -164,6 +164,7 @@ static const char *const ctlidstr[] = {
[VP8E_SET_MAX_INTRA_BITRATE_PCT] = "VP8E_SET_MAX_INTRA_BITRATE_PCT",
[VP8E_SET_SHARPNESS] = "VP8E_SET_SHARPNESS",
[VP8E_SET_TEMPORAL_LAYER_ID] = "VP8E_SET_TEMPORAL_LAYER_ID",
+[VP8E_SET_SCREEN_CONTENT_MODE] = "VP8E_SET_SCREEN_CONTENT_MODE",
#if CONFIG_LIBVPX_VP9_ENCODER
[VP9E_SET_LOSSLESS]= "VP9E_SET_LOSSLESS",
[VP9E_SET_TILE_COLUMNS]= "VP9E_SET_TILE_COLUMNS",
@@ -1262,6 +1263,16 @@ static av_cold int vpx_init(AVCodecContext *avctx,
#endif
}
#endif
+#ifdef VPX_CTRL_VP8E_SET_SCREEN_CONTENT_MODE
+if (avctx->codec_id == AV_CODEC_ID_VP8 && ctx->tune_content >= 0) {
+ if (ctx->tune_content == 2 && ctx->is_alpha) {
+av_log(avctx, AV_LOG_ERROR,
+ "Transparency encoding with screen mode with aggressive rate
control not supported\n");
+return AVERROR(EINVAL);
+ }
+ codecctl_int(avctx, VP8E_SET_SCREEN_CONTENT_MODE, ctx->tune_content);
+}
+#endif
av_log(avctx, AV_LOG_DEBUG, "Using deadline: %d\n", ctx->deadline);
@@ -1379,14 +1390,15 @@ static int storeframe(AVCodecContext *avctx, struct
FrameListData *cx_frame,
* @return AVERROR(ENOMEM) on coded frame queue data allocation error
*/
static int queue_frames(AVCodecContext *avctx, struct vpx_codec_ctx *encoder,
-struct FrameListData **frame_list, AVPacket *pkt_out)
+struct FrameListData **frame_list, AVPacket *pkt_out,
+int queue_only, int *frame_enc)
{
VPxContext *ctx = avctx->priv_data;
const struct vpx_codec_cx_pkt *pkt;
const void *iter = NULL;
int size = 0;
-if (!ctx->is_alpha && *frame_list) {
+if (!queue_only && *frame_list) {
struct FrameListData *cx_frame = *frame_list;
/* return the leading frame if we've already begun queueing */
size = storeframe(avctx, cx_frame, NULL, pkt_out);
@@ -1401,7 +1413,7 @@ static int queue_frames(AVCodecContext *avctx, struct
vpx_codec_ctx *encoder,
while (pkt = vpx_codec_get_cx_data(encoder, &iter)) {
switch (pkt->kind) {
case VPX_CODEC_CX_FRAME_PKT:
-if (!ctx->is_alpha && !size) {
+if (!queue_only && !size) {
struct FrameListData cx_frame;
/* avoid storing the frame when the list is empty and we
haven't yet
@@ -1411,6 +1423,8 @@ static int queue_frames(AVCodecContext *avctx, struct
vpx_codec_ctx *encoder,
size = storeframe(avctx, &cx_frame, NULL, pkt_out);
if (size < 0)
return size;
+if (size > 0)
+*frame_enc = 1;
} else {
struct FrameListData *cx_frame = av_malloc(sizeof(*cx_frame));
@@ -1430,6 +1444,8 @@ static int queue_frames(AVCodecContext *avctx, struct
vpx_codec_ctx *encoder,
return AVERROR(ENOMEM);
}
memcpy(cx_frame->buf, pkt->data.frame.buf, pkt->data.frame.sz);
+if (pkt->data.frame.sz > 0)
+ *frame_enc = 1;
coded_frame_add(frame_list, cx_frame);
}
break;
@@ -1693,6 +1709,7 @@ static int vpx_encode(AVCodecContext *avctx, AVPacket
*pkt,
vpx_svc_layer_id_t layer_id;
int layer_id_valid = 0;
unsigned long duratio
Re: [FFmpeg-devel] Sovereign Tech Fund
Hi, Le keskiviikkona 31. tammikuuta 2024, 16.10.02 EET Jonatas L. Nogueira via ffmpeg-devel a écrit : > > IMO hasty actions and avoidable drama may cause damage to the project > > What would be a hasty action? I've seen far too much people calling action > over stuff discussed for weeks/months as "hasty" in attempt to stall into > endless discussions, so you might want to clarify. Would you care to clarify which astronomical body do you count weeks and months in? I believe that it is customary to use Earth units when you do not specify. And in this case, the topic was brought to the community just about 0.5 week, or 0.11 month ago. Sarcasm aside, I take that to mean that SPI has been involved with those discussions for months in a private and closed process. Michael asserted that an open inclusive process is better than the usual closed approach whence the funding goes through a company. It looks to me that those SPI discussions were just as opaque and closed, and all the talk of openess is just pretense. It does not help that Michael, and now you too, misrepresent any challenge to SPI proposed *process* as an attempt to reject the idea of STF sponsorship, under the convenient pretext that there is not enough time. This is further aggravated by the context that Michael brought forward the idea of funding developers through SPI 3 months ago (in actual Earth units). From your statement, I have to infer that Thilo, Michael and SPI already knew of the STF plan and concealed that key piece of contextual information back then. In hindsight, it feels hypocritical to me that they were arguing for the SPI path, and against the corporate path, on the basis of openess already then, to be honest. I can only agree with Anton that this looks like an attempt to strongarm the community. This is ostensibly being to ignore all the objections that were already brought in October and are being brought again now, with the complicity of SPI. I can't say that this looks well on SPI, but that's just my personal opinion. With all that said, I don't think anybody will attempt to prevent this from happening (if they even can?). But that will take place without the consent of the GA, without any legitimacy on the claims of openess and inclusiveness, and obviously without any form of preclearance from the technical appropriateness of the resulting code contributions. -- レミ・デニ-クールモン http://www.remlab.net/ ___ 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] Sovereign Tech Fund
Forgot to mention, but you also don't need to set the values yourself. You can simply post "we're looking to have X task done, interested parties please send us a quote" and see if it fits the budget. -- Jonatas L. Nogueira (“jesusalva”) Board of Directors Member Software in the Public Interest, Inc. On Wed, Jan 31, 2024 at 1:00 PM Jonatas L. Nogueira wrote: > > The FFmpeg community was told about this three days ago. > > Fair enough if it's true (I'm an outsider, after all) > > > There are arguments in this very thread how we cannot discuss things in > > detail and must instead ACT NOW OR ALL THE MONEY IS GONE. Naturally this > > makes the mood more tense, especially given the other circumstances. > > What I noticed (as an external observator), was putting the cart ahead of > the horse. There's no money right now, but STF is willing to grant around > 200k if FFmpeg is able to submit a Scope of Work in time for their meeting > (happening on Feb 14th, materials however should be submitted 48 hours > before). The scope of work is, in other words, a letter of intentions of > what to do with such money. They have already informed about the > restrictions (e.g. should be maintenance or security related, that it is > too early to ask for feature projects but it might be possible in the > future, etc). > > A Scope of Work is a bit more than a wishlist because it assumes the work > is actually going to be done, so it cannot be too overambitious. That's > what needs to "act now or all the money is gone". The question currently > presented is, "if FFmpeg had 200k euros to work with maintenance, what > would FFmpeg do?" ─ this will become the Scope of Work (we can have people > to word it into legalese later, if needed). > > Of course, all that will end in a Statement of Work (SOW) later, > describing how the wishlist in the Scope of Work will be attained as > everyone knows that money doesn't magically solve problems. And from what > I've seen as an external observer, there is a lot of discussion pending for > this. But that's alright, there's probably over a month for that. Of > course, without a Scope of Work, there'll be no SOW, and any discussion > made on this will become a waste of time. > > If I were the one doing it... I would first make a wishlist in a shared > document with all tasks eligible (3~5 days, so completion until Feb 5th > latest). There are time constraints, though, and FFmpeg takes decisions > collectively, so... I would make a vote between Feb 5th and Feb 12th (yes, > the deadline) to elect the tasks which will be on the Scope of Work. I > would improvise a bit: ask the submitted tasks to also have a proponent > (who is asking for the task to be done) and a budget (how much money the > proponent thinks that will be enough to attain it). The budget here is > nonsense, it is just to have a metric to decide how many options will go to > the Scope of Work. The proponent is to answer questions the voters may have. > > With that laid out and once in motion, the remainder of discussion would > be held. How much to pay the contributors, the actual budget for the > approved projects, how it'll be tracked, what's more fair for deliverables, > how they'll be checked, if you'll contract the developers directly or with > an intermediary, etc. There's no point discussing any of that unless you're > sure the scope of work can be delivered in time. Multiple Statements of > Work are also possible, so there's no actual need for one-size-fits-all in > those questions. If project A, B and C can be divided into commits but > project D cannot, it's fine to have different rules for project D. Also why > it doesn't make much sense to hold these discussions now, when you can't > even answer what would be the projects. > > That, however, is not my call. I can provide suggestions, but actually > coming with a Scope of Work in time is yours and yours alone. > > > So far it does not seem we have an abundance of volunteers, so it seems > > more likely we'll struggle to spend all the money. > > Coincidentally, that happens a lot. No reason to let it hinder you, > though, having money gives the option to make job postings, and you might > even be able to ask for help in spi-general list. > > > only a minority of time is spent typing code. > > Don't I know it... I'm also a programmer for The Mana World, pretty > familiar with "I changed a couple lines and now nothing works, spend two > hours trying to figure out that I forgot a curly brace". > > That is among the discussions I believe FFmpeg should have, although you > might want to have the Scope of Work rolling before starting this. (And > there are many possible solutions, so I expect quite some time to be spent > finding all of them and picking out the best one). > > If you start discussing how to properly pay for the hours spent hunting > simple typo mistakes now, you'll never be able to tell STF what actually > needs to be done in time. > > -- > Jonatas L. Nogueira
Re: [FFmpeg-devel] Sovereign Tech Fund
> The FFmpeg community was told about this three days ago. Fair enough if it's true (I'm an outsider, after all) > There are arguments in this very thread how we cannot discuss things in > detail and must instead ACT NOW OR ALL THE MONEY IS GONE. Naturally this > makes the mood more tense, especially given the other circumstances. What I noticed (as an external observator), was putting the cart ahead of the horse. There's no money right now, but STF is willing to grant around 200k if FFmpeg is able to submit a Scope of Work in time for their meeting (happening on Feb 14th, materials however should be submitted 48 hours before). The scope of work is, in other words, a letter of intentions of what to do with such money. They have already informed about the restrictions (e.g. should be maintenance or security related, that it is too early to ask for feature projects but it might be possible in the future, etc). A Scope of Work is a bit more than a wishlist because it assumes the work is actually going to be done, so it cannot be too overambitious. That's what needs to "act now or all the money is gone". The question currently presented is, "if FFmpeg had 200k euros to work with maintenance, what would FFmpeg do?" ─ this will become the Scope of Work (we can have people to word it into legalese later, if needed). Of course, all that will end in a Statement of Work (SOW) later, describing how the wishlist in the Scope of Work will be attained as everyone knows that money doesn't magically solve problems. And from what I've seen as an external observer, there is a lot of discussion pending for this. But that's alright, there's probably over a month for that. Of course, without a Scope of Work, there'll be no SOW, and any discussion made on this will become a waste of time. If I were the one doing it... I would first make a wishlist in a shared document with all tasks eligible (3~5 days, so completion until Feb 5th latest). There are time constraints, though, and FFmpeg takes decisions collectively, so... I would make a vote between Feb 5th and Feb 12th (yes, the deadline) to elect the tasks which will be on the Scope of Work. I would improvise a bit: ask the submitted tasks to also have a proponent (who is asking for the task to be done) and a budget (how much money the proponent thinks that will be enough to attain it). The budget here is nonsense, it is just to have a metric to decide how many options will go to the Scope of Work. The proponent is to answer questions the voters may have. With that laid out and once in motion, the remainder of discussion would be held. How much to pay the contributors, the actual budget for the approved projects, how it'll be tracked, what's more fair for deliverables, how they'll be checked, if you'll contract the developers directly or with an intermediary, etc. There's no point discussing any of that unless you're sure the scope of work can be delivered in time. Multiple Statements of Work are also possible, so there's no actual need for one-size-fits-all in those questions. If project A, B and C can be divided into commits but project D cannot, it's fine to have different rules for project D. Also why it doesn't make much sense to hold these discussions now, when you can't even answer what would be the projects. That, however, is not my call. I can provide suggestions, but actually coming with a Scope of Work in time is yours and yours alone. > So far it does not seem we have an abundance of volunteers, so it seems > more likely we'll struggle to spend all the money. Coincidentally, that happens a lot. No reason to let it hinder you, though, having money gives the option to make job postings, and you might even be able to ask for help in spi-general list. > only a minority of time is spent typing code. Don't I know it... I'm also a programmer for The Mana World, pretty familiar with "I changed a couple lines and now nothing works, spend two hours trying to figure out that I forgot a curly brace". That is among the discussions I believe FFmpeg should have, although you might want to have the Scope of Work rolling before starting this. (And there are many possible solutions, so I expect quite some time to be spent finding all of them and picking out the best one). If you start discussing how to properly pay for the hours spent hunting simple typo mistakes now, you'll never be able to tell STF what actually needs to be done in time. -- Jonatas L. Nogueira (“jesusalva”) Board of Directors Member Software in the Public Interest, Inc. On Wed, Jan 31, 2024 at 12:17 PM Kieran Kunhya wrote: > On Wed, 31 Jan 2024 at 14:10, Jonatas L. Nogueira via ffmpeg-devel < > ffmpeg-devel@ffmpeg.org> wrote: > >> > IMO hasty actions and avoidable drama may cause damage to the project >> >> What would be a hasty action? I've seen far too much people calling action >> over stuff discussed for weeks/months as "hasty" in attempt to stall into >> endless discussions, so you might wan
Re: [FFmpeg-devel] [PATCH] configure: autodetect libglslang ldflags
Jan 22, 2024, 22:19 by mar...@martin.st:
> On Mon, 22 Jan 2024, Lynne wrote:
>
>> Jan 22, 2024, 07:52 by ffmpeg-devel@ffmpeg.org:
>>
>>> Since glslang 14.0.0, OGLCompiler and HLSL stub libraries have been
>>> fully removed from the build.
>>>
>>> This fixes the configuration by detecting if the stub libraries are
>>> still present (glslang releases before version 14.0.0).
>>>
>>> ffbuild/config.log:
>>> /usr/lib/gcc/x86_64-pc-linux-gnu/13/../../../../x86_64-pc-linux-gnu/bin/ld:
>>> cannot find -lOSDependent: No such file or directory
>>> /usr/lib/gcc/x86_64-pc-linux-gnu/13/../../../../x86_64-pc-linux-gnu/bin/ld:
>>> cannot find -lHLSL: No such file or directory
>>> /usr/lib/gcc/x86_64-pc-linux-gnu/13/../../../../x86_64-pc-linux-gnu/bin/ld:
>>> cannot find -lOGLCompiler: No such file or directory
>>>
>>> Addresses https://trac.ffmpeg.org/ticket/10713
>>> See https://bugs.gentoo.org/show_bug.cgi?id=918989
>>> Should fix https://ffmpeg.org/pipermail/ffmpeg-devel/2023-August/313666.html
>>>
>>> Signed-off-by: Matthew White
>>> ---
>>> configure | 23 +--
>>> 1 file changed, 21 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/configure b/configure
>>> index c8ae0a061d..abff488dc0 100755
>>> --- a/configure
>>> +++ b/configure
>>> @@ -2626,6 +2626,7 @@ CMDLINE_SET="
>>> ignore_tests
>>> install
>>> ld
>>> +libglslang_ldflags
>>> ln_s
>>> logfile
>>> malloc_prefix
>>> @@ -6652,6 +6653,24 @@ if enabled_all libglslang libshaderc; then
>>> die "ERROR: libshaderc and libglslang are mutually exclusive, if in doubt,
>>> disable libglslang"
>>> fi
>>>
>>> +if enabled libglslang; then
>>> +if [ -x "$(command -v glslang)" ]; then
>>> +# https://github.com/KhronosGroup/glslang
>>> +# commit 6be56e45e574b375d759b89dad35f780bbd4792f: Remove
>>> `OGLCompiler` and `HLSL` stub libraries from build
>>> +# StandAlone/StandAlone.cpp:
>>> "SpirvGeneratorVersion:GLSLANG_VERSION_MAJOR.GLSLANG_VERSION_MINOR.GLSLANG_VERSION_PATCH
>>> GLSLANG_VERSION_FLAVOR"
>>> +glslang_version="$(glslang -dumpversion)"
>>> +glslang_major="${glslang_version%%.*}"
>>> +glslang_major="${glslang_major#*:}"
>>> +if test ${glslang_major} -le 13; then
>>> +libglslang_ldflags=" -lOSDependent -lHLSL -lOGLCompiler"
>>> +elif ! [[ ${glslang_major} =~ ^[0-9]+$ ]]; then
>>> +die "ERROR: glslang's computed major version isn't a number:
>>> '${glslang_major}'"
>>> +fi
>>> +else
>>> +die "ERROR: glslang binary not found, impossible to determine
>>> installed glslang's version"
>>> +fi
>>> +fi
>>> +
>>> check_cpp_condition winrt windows.h
>>> "!WINAPI_FAMILY_PARTITION(WINAPI_PARTITION_DESKTOP)"
>>>
>>> if ! disabled w32threads && ! enabled pthreads; then
>>> @@ -6771,10 +6790,10 @@ enabled libfreetype && require_pkg_config
>>> libfreetype freetype2 "ft2build.
>>> enabled libfribidi&& require_pkg_config libfribidi fribidi
>>> fribidi.h fribidi_version_info
>>> enabled libharfbuzz && require_pkg_config libharfbuzz harfbuzz hb.h
>>> hb_buffer_create
>>> enabled libglslang && { check_lib spirv_compiler
>>> glslang/Include/glslang_c_interface.h glslang_initialize_process \
>>> --lglslang -lMachineIndependent -lOSDependent
>>> -lHLSL -lOGLCompiler -lGenericCodeGen \
>>> +-lglslang -lMachineIndependent
>>> "${libglslang_ldflags}" -lGenericCodeGen \
>>> -lSPVRemapper -lSPIRV -lSPIRV-Tools-opt -lSPIRV-Tools -lpthread -lstdc++
>>> -lm ||
>>> require spirv_compiler glslang/Include/glslang_c_interface.h
>>> glslang_initialize_process \
>>> --lglslang -lOSDependent -lHLSL -lOGLCompiler \
>>> +-lglslang "${libglslang_ldflags}" \
>>> -lSPVRemapper -lSPIRV -lSPIRV-Tools-opt -lSPIRV-Tools -lpthread -lstdc++
>>> -lm; }
>>> enabled libgme&& { check_pkg_config libgme libgme gme/gme.h
>>> gme_new_emu ||
>>> require libgme gme/gme.h gme_new_emu -lgme -lstdc++; }
>>> --
>>> 2.43.0
>>>
>>
>> This is very very cursed. Fitting for the public API of the world's fifth
>> worst library. Debian is stuck on version 13, so the majority of users are
>> still stuck on version 13. Debian ships a pkg-config file, but of course
>> it's incorrect, if you try to compile against it. Oh, and libshaderc in
>> Debian ships with a bug such that it segfaults on init, so it's not like you
>> can avoid that. And that package's pkg-config file got broken in the past.
>>
>> I think this is fine for now. I'll let it be discussed for a few more days
>> before merging it.
>>
>
> I think breaking cross compilation with glslang is pretty bad. Apparently VLC
> doesn't enable glslang in their ffmpeg builds though, but I would expect that
> some does.
>
> Wouldn't it just be possible to test whether linkins succeeds with one set of
> libraries, and if not, try with the other set, and pick whichever set works
> wi
Re: [FFmpeg-devel] Sovereign Tech Fund
On Wed, 31 Jan 2024 at 14:10, Jonatas L. Nogueira via ffmpeg-devel < ffmpeg-devel@ffmpeg.org> wrote: > > IMO hasty actions and avoidable drama may cause damage to the project > > What would be a hasty action? I've seen far too much people calling action > over stuff discussed for weeks/months as "hasty" in attempt to stall into > endless discussions, so you might want to clarify. > The FFmpeg community was told about this three days ago. 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] Sovereign Tech Fund
Quoting Jonatas L. Nogueira via ffmpeg-devel (2024-01-31 15:10:02) > > IMO hasty actions and avoidable drama may cause damage to the project > > What would be a hasty action? I've seen far too much people calling action > over stuff discussed for weeks/months as "hasty" in attempt to stall into > endless discussions, so you might want to clarify. There are arguments in this very thread how we cannot discuss things in detail and must instead ACT NOW OR ALL THE MONEY IS GONE. Naturally this makes the mood more tense, especially given the other circumstances. > > The question is, what exactly would be the reprecussion for failing to > achieve projects. To us? To SPI? Not to mention the developer not > getting paid. > > Given the current goal is to fund continuous maintenance tasks, it'll only > be a large problem with unpaid people if final state isn't better than > initial (eg. code gets more bloated instead of less). Otherwise, even if > some specific task cannot be completed, that's not an issue by itself, the > time already spent can be paid, as long that there's something to show for > it. (That's also an issue, but thankfully a debate for later). > > Of course, if everything ends up unfinished that'll only scream you're > terrible at planning or outright don't know what you're doing. > Repercussions could make harder for you to acquire funds in the future and > likely comments that SPI should follow its projects more closely. > > So mixing some easy but boring tasks is definitely a good idea. > > > So you're basically saying the developers have to take the risk onto > themselves > > Could you explain what exactly the risk devs are taking is? I can help if > you can make the usual risk assessment table (what risk, likelihood, and > impact/consequence). The risk for the developers is spending a lot of time and not getting paid accordingly. I see the danger of that happening when the project depends on the delivery of some specific milestone, which * is never reached because of disagreements during review * turns out to require significantly more effort than it was budgeted for The only proposed way of avoiding these is for every project to be either: * Decomposable into very small discrete tasks, which is doable only in some cases. * Of the form 'work towards X', but then evaluation becomes more tricky. > > it's widely acknowledged that > accurate time estimates for complex projects are somewhere between > extremely hard and unfeasible. > > I don't think a year is a question of accuracy, it usually indicates that > the code is becoming lasagna (if no result can be provided), ravioli (if > result can be provided but it doesn't work) or spaghetti (when it can be > provided and works... sometimes). > > That sounds exactly like a good use for a maintenance grant, identifying > where the existing code base is problematic and trying to tidy it up. > That's also not something you can say "will be done by X", it's just > something you pour hours and hope end result is easier to work with than > the previous state (even if it's still pasta). > > That's why the Scope of Work (which is the current task) for this is less > concerned in end results or deadlines, but in goals which can be attained > within a time frame (even if they're "making better" or can only be partly > attained, which would cause STF to believe you to be overambitious but is > not as problematic as not attaining anything at all). > > > developers will try to protect themselves by playing it safe > and budgeting for the largest amount of time they think they might > possibly need. Which means in most cases they will need less time, > sometimes significantly less. Would STF be okay with us being so > wasteful? > > No one is going to get paid according to their budget, the payment is over > how much time they actually spent. Budget is a limit, so the developer has > a good idea since the start of how long they can take. If they notice it'll > go over budget, they can stop, reevaluate and propose new budgets or > partial deliveries (or whatever the GA/STF decides to be acceptable). More > often than not, they'll have run in an unforeseen issue which could warrant > a fund/budget on its own. > > So if you budget 15 hours and work 5, you'll be paid for 5 and the surplus > of 10 hours can be given to other projects or assigned somewhere nearing > over budgeting so it can be finished (or at least, delivered). So far it does not seem we have an abundance of volunteers, so it seems more likely we'll struggle to spend all the money. > > my main point is that the amount of work to be done on any > interesting cleanup is unknowable beforehand. That means you have to > budget for the worst case, which means in the median case you will be > significantly overpaid. > > I agree it's impossible to know, and I am sure STF is aware of that as > well. That's also why particulars usually don't fund these things, but > public funds like STF are
Re: [FFmpeg-devel] [PATCH v5 0/6] Add mp4 and ts support for vvc
On Tue, Jan 30, 2024 at 8:49 PM Nuo Mi wrote: > Changes since v4: > mp4: return patch welcome for CENC nal units (Thomas) > mp4: reintroduce vvc back into ff_codec_movvideo_tags since the mp4 > demuxer relies on it. (James) > > Nuo Mi (4): > avformat/mpegtsenc: refact mpegts_check_bitstream to loop up table > avformat/mpegtsenc: refact, move h264, hevc startcode checking to > check_h26x_startcode > avformat/mpegtsenc: refact, remove h264, hevc magic numbers for > nal_type > avformat/mpegtsenc: refact out h26x_prefix_aud > > Thomas Siedel (2): > avformat/mp4: add muxer support for H266/VVC > avformat/mpegts: add ts stream types for H266/VVC > > configure | 2 +- > libavformat/Makefile| 6 +- > libavformat/isom.c | 1 + > libavformat/isom_tags.c | 3 + > libavformat/mov.c | 6 + > libavformat/movenc.c| 40 +- > libavformat/mpeg.c | 3 + > libavformat/mpeg.h | 1 + > libavformat/mpegts.c| 2 + > libavformat/mpegts.h| 1 + > libavformat/mpegtsenc.c | 173 --- > libavformat/vvc.c | 971 > libavformat/vvc.h | 99 > 13 files changed, 1241 insertions(+), 67 deletions(-) > create mode 100644 libavformat/vvc.c > create mode 100644 libavformat/vvc.h > Applied. Thank you all for your reviews and comments > > -- > 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] Sovereign Tech Fund
> IMO hasty actions and avoidable drama may cause damage to the project What would be a hasty action? I've seen far too much people calling action over stuff discussed for weeks/months as "hasty" in attempt to stall into endless discussions, so you might want to clarify. > The question is, what exactly would be the reprecussion for failing to achieve projects. To us? To SPI? Not to mention the developer not getting paid. Given the current goal is to fund continuous maintenance tasks, it'll only be a large problem with unpaid people if final state isn't better than initial (eg. code gets more bloated instead of less). Otherwise, even if some specific task cannot be completed, that's not an issue by itself, the time already spent can be paid, as long that there's something to show for it. (That's also an issue, but thankfully a debate for later). Of course, if everything ends up unfinished that'll only scream you're terrible at planning or outright don't know what you're doing. Repercussions could make harder for you to acquire funds in the future and likely comments that SPI should follow its projects more closely. So mixing some easy but boring tasks is definitely a good idea. > So you're basically saying the developers have to take the risk onto themselves Could you explain what exactly the risk devs are taking is? I can help if you can make the usual risk assessment table (what risk, likelihood, and impact/consequence). > it's widely acknowledged that accurate time estimates for complex projects are somewhere between extremely hard and unfeasible. I don't think a year is a question of accuracy, it usually indicates that the code is becoming lasagna (if no result can be provided), ravioli (if result can be provided but it doesn't work) or spaghetti (when it can be provided and works... sometimes). That sounds exactly like a good use for a maintenance grant, identifying where the existing code base is problematic and trying to tidy it up. That's also not something you can say "will be done by X", it's just something you pour hours and hope end result is easier to work with than the previous state (even if it's still pasta). That's why the Scope of Work (which is the current task) for this is less concerned in end results or deadlines, but in goals which can be attained within a time frame (even if they're "making better" or can only be partly attained, which would cause STF to believe you to be overambitious but is not as problematic as not attaining anything at all). > developers will try to protect themselves by playing it safe and budgeting for the largest amount of time they think they might possibly need. Which means in most cases they will need less time, sometimes significantly less. Would STF be okay with us being so wasteful? No one is going to get paid according to their budget, the payment is over how much time they actually spent. Budget is a limit, so the developer has a good idea since the start of how long they can take. If they notice it'll go over budget, they can stop, reevaluate and propose new budgets or partial deliveries (or whatever the GA/STF decides to be acceptable). More often than not, they'll have run in an unforeseen issue which could warrant a fund/budget on its own. So if you budget 15 hours and work 5, you'll be paid for 5 and the surplus of 10 hours can be given to other projects or assigned somewhere nearing over budgeting so it can be finished (or at least, delivered). > my main point is that the amount of work to be done on any interesting cleanup is unknowable beforehand. That means you have to budget for the worst case, which means in the median case you will be significantly overpaid. I agree it's impossible to know, and I am sure STF is aware of that as well. That's also why particulars usually don't fund these things, but public funds like STF are willing to. But there will be no overpayment, as you're paid for what you do (up to budget). If you finish with less than budgeted, that means the surplus can be used to clean another code. (And if there's a concern of fake hours, there are mechanisms which can be used and can be discussed later, after the budget is made, which is after STF returns their approval and the exact terms). I hope this addresses some of your concerns. Att., Jonatas L. Nogueira (“Jesusalva”) On Wed, Jan 31, 2024, 09:59 Anton Khirnov wrote: > Quoting Michael Niedermayer (2024-01-30 01:15:54) > > > Self-imposed restrictions like these at the very least need a GA vote > > > IMO. > > > > I dont think its a "Self-imposed restriction" > > The right to arbitrarily reject a invoice to a SoW never existed in the > > first place. > > But lets try this hypothetically. > > If the GA decides it has the right to reject an invoice to a SoW > > signed between SPI/STF/1 Developer. > > Where would the GA get that right from ? > > It can only have gained that right from the SoW/ or a contract > > > > This is the same in GSoC > > if the GA deci
Re: [FFmpeg-devel] configure doesn't seem to use pkg-config flags?
On 31/01/2024 14:07, epira...@gmail.com wrote:
On 31 Jan 2024, at 13:03, Timo Rothenpieler wrote:
On 31/01/2024 05:31, Roger Pack wrote:
On Thu, Jan 18, 2024 at 6:31 AM Timo Rothenpieler wrote:
On 18/01/2024 04:38, Roger Pack wrote:
Hello.
After compiling libx265 as a "static library" (mingw cross compiling
targeting win64)
$ pkg-config --libs --static x265
-L/home/rdp/new/sandbox/win64_static/build_files/lib -lx265
/usr/lib/gcc/x86_64-w64-mingw32/10-win32/libstdc++.a -lgcc
I get this failure at configure time:
./configure --enable-libx265 --arch=x86_64 --target-os=mingw32
--cross-prefix=x86_64-w64-mingw32- --pkg-config=pkg-config
--pkg-config-flags=--static
ERROR: x265 not found using pkg-config
config.log (sorry it's verbose, first compile passes, second one fails linking)
...
require_pkg_config libx265 x265 x265.h x265_api_get
check_pkg_config libx265 x265 x265.h x265_api_get
test_pkg_config libx265 x265 x265.h x265_api_get
pkg-config --exists --print-errors x265
check_func_headers x265.h x265_api_get
-I/home/rdp/new/sandbox/win64_static/build_files/include
-L/home/rdp/new/sandbox/win64_static/build_files/lib -lx265
/usr/lib/gcc/x86_64-w64-mingw32/10-win32/libstdc++.a -lgcc
test_ld cc -I/home/rdp/new/sandbox/win64_static/build_files/include
-L/home/rdp/new/sandbox/win64_static/build_files/lib -lx265
/usr/lib/gcc/x86_64-w64-mingw32/10-win32/libstdc++.a -lgcc
test_cc -I/home/rdp/new/sandbox/win64_static/build_files/include
-L/home/rdp/new/sandbox/win64_static/build_files/lib
/usr/lib/gcc/x86_64-w64-mingw32/10-win32/libstdc++.a
BEGIN /tmp/ffconf.L9GhKESq/test.c
1 #include
2 #include
3 long check_x265_api_get(void) { return (long) x265_api_get; }
4 int main(void) { int ret = 0;
5ret |= ((intptr_t)check_x265_api_get) & 0x;
6 return ret; }
END /tmp/ffconf.L9GhKESq/test.c
x86_64-w64-mingw32-gcc -D_ISOC99_SOURCE -D_FILE_OFFSET_BITS=64
-D_LARGEFILE_SOURCE -U__STRICT_ANSI__ -D__USE_MINGW_ANSI_STDIO=1
-D__printf__=__gnu_printf__ -D_WIN32_WINNT=0x0600
-D_POSIX_C_SOURCE=200112 -D_XOPEN_SOURCE=600 -DPIC -std=c11
-fomit-frame-pointer
-I/home/rdp/new/sandbox/win64_static/build_files/include
-L/home/rdp/new/sandbox/win64_static/build_files/lib
/usr/lib/gcc/x86_64-w64-mingw32/10-win32/libstdc++.a -c -o
/tmp/ffconf.L9GhKESq/test.o /tmp/ffconf.L9GhKESq/test.c
/tmp/ffconf.L9GhKESq/test.c: In function 'check_x265_api_get':
/tmp/ffconf.L9GhKESq/test.c:3:40: warning: cast from pointer to
integer of different size [-Wpointer-to-int-cast]
3 | long check_x265_api_get(void) { return (long) x265_api_get; }
|^
x86_64-w64-mingw32-gcc: warning:
/usr/lib/gcc/x86_64-w64-mingw32/10-win32/libstdc++.a: linker input
file unused because linking not done
x86_64-w64-mingw32-gcc -Wl,--nxcompat,--dynamicbase
-Wl,--high-entropy-va -Wl,--as-needed -Wl,--image-base,0x14000
-I/home/rdp/new/sandbox/win64_static/build_files/include
-L/home/rdp/new/sandbox/win64_static/build_files/lib
/usr/lib/gcc/x86_64-w64-mingw32/10-win32/libstdc++.a -o
/tmp/ffconf.L9GhKESq/test.exe /tmp/ffconf.L9GhKESq/test.o -lx265 -lgcc
/usr/bin/x86_64-w64-mingw32-ld:
/home/rdp/new/sandbox/win64_static/build_files/lib/libx265.a(api.cpp.obj):api.cpp:(.text+0xfb5):
undefined reference to `operator new(unsigned long long)'
/usr/bin/x86_64-w64-mingw32-ld:
/home/rdp/new/sandbox/win64_static/build_files/lib/libx265.a(api.cpp.obj):api.cpp:(.text+0x1303):
undefined reference to `operator delete(void*)'
...
So it seems to be linking it not using the output of pkg-config --libs
--static for linking or something?
It's passing the pkg-config flags just fine.
The x265 .pc file is just broken and does not state its dependency on
libstdc++
x265.pc does list libstdc++
$ pkg-config --libs --static x265
-L/home/rdp/new/sandbox/win64_static/build_files/lib -lx265
/usr/lib/gcc/x86_64-w64-mingw32/10-win32/libstdc++.a -lgcc
I don't think that's a valid way to specify libs by absolute path.
There is nothing invalid about that, to my knowledge.
At least configure doesn't think so, it specifically looks for stuff starting with
"-l" and discards the rest. Try adding -l: to the beginning.
Just adding -l to the beginning does sound invalid though.
That's why I said -l:
You could do -L/usr/lib/gcc/x86_64-w64-mingw32/10-win32/ -lstdc++
But it should work just fine the way it is, I do not think discarding
everything not starting with -l is correct.
When I configure ffmpeg I specify ./configure --pkg-config-flags=--static
But it appears to be rearranging the order when configure tries to use it?
x86_64-w64-mingw32-gcc: warning:
/usr/lib/gcc/x86_64-w64-mingw32/10-win32/libstdc++.a: linker input
file unused because linking not done
x86_64-w64-mingw32-gcc -Wl,--nxcompat,--dynamicbase
-Wl,--high-entropy-va -Wl,--as-needed -Wl,--image-base,0x14000
-I/home/rdp/new/sandbox/win64_static/build_files/include
-L/home/rdp/new/sandbox/win64_static/build_
Re: [FFmpeg-devel] configure doesn't seem to use pkg-config flags?
On 31 Jan 2024, at 13:03, Timo Rothenpieler wrote:
> On 31/01/2024 05:31, Roger Pack wrote:
>> On Thu, Jan 18, 2024 at 6:31 AM Timo Rothenpieler
>> wrote:
>>>
>>>
>>>
>>> On 18/01/2024 04:38, Roger Pack wrote:
Hello.
After compiling libx265 as a "static library" (mingw cross compiling
targeting win64)
$ pkg-config --libs --static x265
-L/home/rdp/new/sandbox/win64_static/build_files/lib -lx265
/usr/lib/gcc/x86_64-w64-mingw32/10-win32/libstdc++.a -lgcc
I get this failure at configure time:
./configure --enable-libx265 --arch=x86_64 --target-os=mingw32
--cross-prefix=x86_64-w64-mingw32- --pkg-config=pkg-config
--pkg-config-flags=--static
ERROR: x265 not found using pkg-config
config.log (sorry it's verbose, first compile passes, second one fails
linking)
...
require_pkg_config libx265 x265 x265.h x265_api_get
check_pkg_config libx265 x265 x265.h x265_api_get
test_pkg_config libx265 x265 x265.h x265_api_get
pkg-config --exists --print-errors x265
check_func_headers x265.h x265_api_get
-I/home/rdp/new/sandbox/win64_static/build_files/include
-L/home/rdp/new/sandbox/win64_static/build_files/lib -lx265
/usr/lib/gcc/x86_64-w64-mingw32/10-win32/libstdc++.a -lgcc
test_ld cc -I/home/rdp/new/sandbox/win64_static/build_files/include
-L/home/rdp/new/sandbox/win64_static/build_files/lib -lx265
/usr/lib/gcc/x86_64-w64-mingw32/10-win32/libstdc++.a -lgcc
test_cc -I/home/rdp/new/sandbox/win64_static/build_files/include
-L/home/rdp/new/sandbox/win64_static/build_files/lib
/usr/lib/gcc/x86_64-w64-mingw32/10-win32/libstdc++.a
BEGIN /tmp/ffconf.L9GhKESq/test.c
1 #include
2 #include
3 long check_x265_api_get(void) { return (long) x265_api_get; }
4 int main(void) { int ret = 0;
5ret |= ((intptr_t)check_x265_api_get) & 0x;
6 return ret; }
END /tmp/ffconf.L9GhKESq/test.c
x86_64-w64-mingw32-gcc -D_ISOC99_SOURCE -D_FILE_OFFSET_BITS=64
-D_LARGEFILE_SOURCE -U__STRICT_ANSI__ -D__USE_MINGW_ANSI_STDIO=1
-D__printf__=__gnu_printf__ -D_WIN32_WINNT=0x0600
-D_POSIX_C_SOURCE=200112 -D_XOPEN_SOURCE=600 -DPIC -std=c11
-fomit-frame-pointer
-I/home/rdp/new/sandbox/win64_static/build_files/include
-L/home/rdp/new/sandbox/win64_static/build_files/lib
/usr/lib/gcc/x86_64-w64-mingw32/10-win32/libstdc++.a -c -o
/tmp/ffconf.L9GhKESq/test.o /tmp/ffconf.L9GhKESq/test.c
/tmp/ffconf.L9GhKESq/test.c: In function 'check_x265_api_get':
/tmp/ffconf.L9GhKESq/test.c:3:40: warning: cast from pointer to
integer of different size [-Wpointer-to-int-cast]
3 | long check_x265_api_get(void) { return (long) x265_api_get; }
|^
x86_64-w64-mingw32-gcc: warning:
/usr/lib/gcc/x86_64-w64-mingw32/10-win32/libstdc++.a: linker input
file unused because linking not done
x86_64-w64-mingw32-gcc -Wl,--nxcompat,--dynamicbase
-Wl,--high-entropy-va -Wl,--as-needed -Wl,--image-base,0x14000
-I/home/rdp/new/sandbox/win64_static/build_files/include
-L/home/rdp/new/sandbox/win64_static/build_files/lib
/usr/lib/gcc/x86_64-w64-mingw32/10-win32/libstdc++.a -o
/tmp/ffconf.L9GhKESq/test.exe /tmp/ffconf.L9GhKESq/test.o -lx265 -lgcc
/usr/bin/x86_64-w64-mingw32-ld:
/home/rdp/new/sandbox/win64_static/build_files/lib/libx265.a(api.cpp.obj):api.cpp:(.text+0xfb5):
undefined reference to `operator new(unsigned long long)'
/usr/bin/x86_64-w64-mingw32-ld:
/home/rdp/new/sandbox/win64_static/build_files/lib/libx265.a(api.cpp.obj):api.cpp:(.text+0x1303):
undefined reference to `operator delete(void*)'
...
So it seems to be linking it not using the output of pkg-config --libs
--static for linking or something?
>>>
>>> It's passing the pkg-config flags just fine.
>>> The x265 .pc file is just broken and does not state its dependency on
>>> libstdc++
>>
>> x265.pc does list libstdc++
>>
>> $ pkg-config --libs --static x265
>> -L/home/rdp/new/sandbox/win64_static/build_files/lib -lx265
>> /usr/lib/gcc/x86_64-w64-mingw32/10-win32/libstdc++.a -lgcc
>
> I don't think that's a valid way to specify libs by absolute path.
There is nothing invalid about that, to my knowledge.
> At least configure doesn't think so, it specifically looks for stuff starting
> with "-l" and discards the rest. Try adding -l: to the beginning.
Just adding -l to the beginning does sound invalid though.
You could do -L/usr/lib/gcc/x86_64-w64-mingw32/10-win32/ -lstdc++
But it should work just fine the way it is, I do not think discarding
everything not starting with -l is correct.
>
>
>> When I configure ffmpeg I specify ./configure --pkg-config-flags=--static
>>
>> But it appears to be rearranging the order when configure tries to use it?
>>
>> x86_64
Re: [FFmpeg-devel] Sovereign Tech Fund
Quoting Michael Niedermayer (2024-01-30 01:15:54) > > Self-imposed restrictions like these at the very least need a GA vote > > IMO. > > I dont think its a "Self-imposed restriction" > The right to arbitrarily reject a invoice to a SoW never existed in the > first place. > But lets try this hypothetically. > If the GA decides it has the right to reject an invoice to a SoW > signed between SPI/STF/1 Developer. > Where would the GA get that right from ? > It can only have gained that right from the SoW/ or a contract > > This is the same in GSoC > if the GA decides a student should not be paid, its not going to > work, its the mentors decission and googles. > The GA never gave that right up, it never had it in the first place My understanding of your > There can be no late objections > [...] > objections after that cannot be considered! was that reviewers of the code produced by an STF-funded project would be restricted from rejecting the patches or demaning large-scale changes. If that is not what you meant then my point does not apply, but then this opens the developer to the risk of their code not being accepted. > > > > > Also once the person doing the work reaches the agreed milestone. > > > She will submit an invoice with stefano and my help to SPI/STF. > > > (in the unlikely case of a dispute on reaching a milestone > > > it would be decided by the technical committee if the milestone > > > has been reached from FFmpegs point of view) > > > > Unlikely? I believe you are overlooking and/or trivializing the most > > serious problems that need to be addressed before we can submit any > > applications and not have it end in disaster. > > yes, iam trivializing, i thought people would value a grant of 200k€ > more than arguing around. IMO hasty actions and avoidable drama may cause damage to the project far in excess of this sum. > And sure some arguments are quite valid i just think we can postpone > what needs to be postponed to get this grant and then for the next > round we can adjust everything as people prefer (in case there then > still is any wish to change something) > > > > > > These are, IMO: > > > > 1) How does the project protect itself from pre-approving some code that > >does not exist yet? This is not just some theoretical danger, it's > >easily possible that some project sounds good in theory, but actually > >implementing it comes with so many gotchas and caveats that it ends > >up being not worth it. Or there are fundamental technical > >disagreements about the specific way it's been implemented. Both > >cases exist in our history. > > Lets see > First STF is not about features but about maintaince. So the risk > of really unexpected and unavoidable sideeffects are not that high. > Also we dont need to do the really tough stuff in STF we can do the > easy but boring stuff. I do not see people queing up for such work. > But whats really the problem here ? > Lets imagine a example we agree to ABC > and it turns out the implemtation of ABC unexpectedly needs 3 letters > and this is unacceptable so we dont merge it. > Personally I would for cases where we arent sure the code is acceptable > for git master. Make this clear to STF before they accepting it and > I would not put "merge into git master" in the SoW. > > Now if we do put something in the SoW that we then do not achieve > thats a failure. IIRC/IIUC this is possible but will not be > tolerated many times. (certainly very dependant also on our > explanation of why that happened) > (thats what i remember, i cannot find the mail ATM where we where told that) The question is, what exactly would be the reprecussion for failing to achieve projects. To us? To SPI? Not to mention the developer not getting paid. > > > >It's also very hard to accurately estimate the amount of work > >required to do something. What do we do when someone spends a month > >working before realizing the project needs 5x more time than it's > >budgeted for? > > use a payment per time SoW. > But honestly as a buisness partner to STF we should aim for delivering > what we promisse at the price we request. > Anything else will not be good for FFmpeg independant of all other things So you're basically saying the developers have to take the risk onto themselves. That's ridiculous and means this cannot be used for almost any interesting projects. As an example, my threading work took over twice the time I initially expected. Are you suggesting I should have worked a year for free? And it's not just my personal failing - it's widely acknowledged that accurate time estimates for complex projects are somewhere between extremely hard and unfeasible. Of course the problem also works in other direction. If we go with your suggestion, developers will try to protect themselves by playing it safe and budgeting for the largest amount of time they think they might possibly need. Which means in most cases they will need
Re: [FFmpeg-devel] Sovereign Tech Fund
Quoting Stefano Sabatini (2024-01-30 00:53:25) > On date Monday 2024-01-29 22:11:49 +0100, Anton Khirnov wrote: > > Quoting Michael Niedermayer (2024-01-28 04:25:49) > > > There can be no late objections here to any project suggestions. > > > Objections must be before a project suggestion is submitted to STF, > > > objections after that cannot be considered! > > > > Self-imposed restrictions like these at the very least need a GA vote > > IMO. > > > > > Also once the person doing the work reaches the agreed milestone. > > > She will submit an invoice with stefano and my help to SPI/STF. > > > (in the unlikely case of a dispute on reaching a milestone > > > it would be decided by the technical committee if the milestone > > > has been reached from FFmpegs point of view) > > > > Unlikely? I believe you are overlooking and/or trivializing the most > > serious problems that need to be addressed before we can submit any > > applications and not have it end in disaster. > > > > These are, IMO: > > The following are good points, I propose some possible solutions. I > think these should be based on the assumptions that failure can > occurr, and the system should be designed to be robust to failures. > > > 1) How does the project protect itself from pre-approving some code that > >does not exist yet? This is not just some theoretical danger, it's > >easily possible that some project sounds good in theory, but actually > >implementing it comes with so many gotchas and caveats that it ends > >up being not worth it. Or there are fundamental technical > >disagreements about the specific way it's been implemented. Both > >cases exist in our history. > > The design and investigative work should be covered as part of the > SOW. In other words, the SOW should also cover the preliminary design > and experimentation. In case it leads to no committable work (which is > unlikely but not impossible), the output should be a document/report > documenting the result of the initial investigation, and the project > might be aborted at that point. > > This should protect both the developer and the project. In each case > it should be assumed that the final result of the investigation would > not lead to committable deliverables, but to design documents which > might lay the foundation of further work (possibly in a different > direction). That might be a viable direction, but it does not really solve the problem. Initial investigation only gets you so far and some issues simply do not become apparent until quite far in the development process. E.g. my recent threading work (that keeps getting mentioned in this thread as an example of what a cleanup project could look like) was largely composed of many "sub-projects", each disentangling a speficic feature or area. And there was no reliable way to predict in advance whether a given sub-project would take two hours or two weeks. -- 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] avcodec: move leb reading functions to its own header
Signed-off-by: James Almer
---
libavcodec/av1_parse.h | 16 +--
libavcodec/bitstream.h | 2 -
libavcodec/bitstream_template.h| 23 --
libavcodec/bsf/extract_extradata.c | 2 +-
libavcodec/get_bits.h | 24 --
libavcodec/leb.h | 70 ++
libavformat/av1dec.c | 2 +-
libavformat/iamf_parse.c | 1 +
8 files changed, 75 insertions(+), 65 deletions(-)
create mode 100644 libavcodec/leb.h
diff --git a/libavcodec/av1_parse.h b/libavcodec/av1_parse.h
index d0abd7ac7c..2b8cce4835 100644
--- a/libavcodec/av1_parse.h
+++ b/libavcodec/av1_parse.h
@@ -30,6 +30,7 @@
#include "av1.h"
#include "get_bits.h"
+#include "leb.h"
// OBU header fields + max leb128 length
#define MAX_OBU_HEADER_SIZE (2 + 8)
@@ -88,19 +89,6 @@ int ff_av1_packet_split(AV1Packet *pkt, const uint8_t *buf,
int length,
*/
void ff_av1_packet_uninit(AV1Packet *pkt);
-static inline int64_t leb128(GetBitContext *gb) {
-int64_t ret = 0;
-int i;
-
-for (i = 0; i < 8; i++) {
-int byte = get_bits(gb, 8);
-ret |= (int64_t)(byte & 0x7f) << (i * 7);
-if (!(byte & 0x80))
-break;
-}
-return ret;
-}
-
static inline int parse_obu_header(const uint8_t *buf, int buf_size,
int64_t *obu_size, int *start_pos, int
*type,
int *temporal_id, int *spatial_id)
@@ -129,7 +117,7 @@ static inline int parse_obu_header(const uint8_t *buf, int
buf_size,
*temporal_id = *spatial_id = 0;
}
-*obu_size = has_size_flag ? leb128(&gb)
+*obu_size = has_size_flag ? get_leb128(&gb)
: buf_size - 1 - extension_flag;
if (get_bits_left(&gb) < 0)
diff --git a/libavcodec/bitstream.h b/libavcodec/bitstream.h
index 17f8a5da83..35b7873b9c 100644
--- a/libavcodec/bitstream.h
+++ b/libavcodec/bitstream.h
@@ -103,7 +103,6 @@
# define bits_apply_signbits_apply_sign_le
# define bits_read_vlc bits_read_vlc_le
# define bits_read_vlc_multi bits_read_vlc_multi_le
-# define bits_read_leb bits_read_leb_le
#elif defined(BITS_DEFAULT_BE)
@@ -133,7 +132,6 @@
# define bits_apply_signbits_apply_sign_be
# define bits_read_vlc bits_read_vlc_be
# define bits_read_vlc_multi bits_read_vlc_multi_be
-# define bits_read_leb bits_read_leb_be
#endif
diff --git a/libavcodec/bitstream_template.h b/libavcodec/bitstream_template.h
index 4c7101632f..4f3d07275f 100644
--- a/libavcodec/bitstream_template.h
+++ b/libavcodec/bitstream_template.h
@@ -562,29 +562,6 @@ static inline int BS_FUNC(read_vlc_multi)(BSCTX *bc,
uint8_t dst[8],
return ret;
}
-/**
- * Read a unsigned integer coded as a variable number of up to eight
- * little-endian bytes, where the MSB in a byte signals another byte
- * must be read.
- * Values > UINT_MAX are truncated, but all coded bits are read.
- */
-static inline unsigned BS_FUNC(read_leb)(BSCTX *bc) {
-int more, i = 0;
-unsigned leb = 0;
-
-do {
-int byte = BS_FUNC(read)(bc, 8);
-unsigned bits = byte & 0x7f;
-more = byte & 0x80;
-if (i <= 4)
-leb |= bits << (i * 7);
-if (++i == 8)
-break;
-} while (more);
-
-return leb;
-}
-
#undef BSCTX
#undef BS_FUNC
#undef BS_JOIN3
diff --git a/libavcodec/bsf/extract_extradata.c
b/libavcodec/bsf/extract_extradata.c
index baa629295f..5d5d80c90f 100644
--- a/libavcodec/bsf/extract_extradata.c
+++ b/libavcodec/bsf/extract_extradata.c
@@ -68,7 +68,7 @@ static int metadata_is_global(const AV1OBU *obu)
if (init_get_bits(&gb, obu->data, obu->size_bits) < 0)
return 0;
-metadata_type = leb128(&gb);
+metadata_type = get_leb(&gb);
return val_in_array(metadata_obu_types, FF_ARRAY_ELEMS(metadata_obu_types),
metadata_type);
diff --git a/libavcodec/get_bits.h b/libavcodec/get_bits.h
index 9e19d2a439..cfcf97c021 100644
--- a/libavcodec/get_bits.h
+++ b/libavcodec/get_bits.h
@@ -94,7 +94,6 @@ typedef BitstreamContext GetBitContext;
#define align_get_bits bits_align
#define get_vlc2bits_read_vlc
#define get_vlc_multi bits_read_vlc_multi
-#define get_leb bits_read_leb
#define init_get_bits8_le(s, buffer, byte_size)
bits_init8_le((BitstreamContextLE*)s, buffer, byte_size)
#define get_bits_le(s, n)
bits_read_le((BitstreamContextLE*)s, n)
@@ -711,29 +710,6 @@ static inline int skip_1stop_8data_bits(GetBitContext *gb)
return 0;
}
-/**
- * Read a unsigned integer coded as a variable number of up to eight
- * little-endian bytes, where the MSB in a byte signals another byte
- * must be read.
- * All coded bits are read, but values > UINT_MAX are truncated.
- */
-static inline unsigned get_leb(GetBitContext *s) {
-int more, i = 0;
-unsigned leb = 0;
-
-do {
-int byte = get_
Re: [FFmpeg-devel] [PATCH 3/4] checkasm/rv34dsp: add rv34_idct_dc_add test
The name was written incorrectly by mistake.. It has been corrected in this
response.
flow gg 于2024年1月31日周三 20:00写道：
>
>
From 126f0b52cb8dd2f8fd5b881a4b166d1680562a0f Mon Sep 17 00:00:00 2001
From: sunyuechi
Date: Wed, 31 Jan 2024 19:01:25 +0800
Subject: [PATCH 3/4] checkasm/rv34dsp: add rv34_idct_dc_add test
---
tests/checkasm/rv34dsp.c | 24
1 file changed, 24 insertions(+)
diff --git a/tests/checkasm/rv34dsp.c b/tests/checkasm/rv34dsp.c
index 56167d2569..5382d5926b 100644
--- a/tests/checkasm/rv34dsp.c
+++ b/tests/checkasm/rv34dsp.c
@@ -56,10 +56,34 @@ static void test_rv34_inv_transform_dc(RV34DSPContext *s) {
report("rv34_inv_transform_dc");
}
+static void test_rv34_idct_dc_add(RV34DSPContext *s) {
+declare_func(void, uint8_t *dst, ptrdiff_t stride, int dc);
+
+if (check_func(s->rv34_idct_dc_add, "rv34_idct_dc_add")) {
+LOCAL_ALIGNED_16(uint8_t, p1, [BUF_SIZE]);
+LOCAL_ALIGNED_16(uint8_t, p2, [BUF_SIZE]);
+
+randomize(p1, BUF_SIZE);
+memcpy(p2, p1, BUF_SIZE * sizeof(*p1));
+
+call_ref(p1, 4, 5);
+call_new(p2, 4, 5);
+
+if (memcmp(p1, p2, BUF_SIZE * sizeof (*p1)) != 0) {
+fail();
+}
+
+bench_new(p1, 4, 5);
+}
+
+report("rv34_idct_dc_add");
+}
+
void checkasm_check_rv34dsp(void)
{
RV34DSPContext s = { 0 };
ff_rv34dsp_init(&s);
test_rv34_inv_transform_dc(&s);
+test_rv34_idct_dc_add(&s);
}
--
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".
Re: [FFmpeg-devel] configure doesn't seem to use pkg-config flags?
On 31/01/2024 05:31, Roger Pack wrote:
On Thu, Jan 18, 2024 at 6:31 AM Timo Rothenpieler wrote:
On 18/01/2024 04:38, Roger Pack wrote:
Hello.
After compiling libx265 as a "static library" (mingw cross compiling
targeting win64)
$ pkg-config --libs --static x265
-L/home/rdp/new/sandbox/win64_static/build_files/lib -lx265
/usr/lib/gcc/x86_64-w64-mingw32/10-win32/libstdc++.a -lgcc
I get this failure at configure time:
./configure --enable-libx265 --arch=x86_64 --target-os=mingw32
--cross-prefix=x86_64-w64-mingw32- --pkg-config=pkg-config
--pkg-config-flags=--static
ERROR: x265 not found using pkg-config
config.log (sorry it's verbose, first compile passes, second one fails linking)
...
require_pkg_config libx265 x265 x265.h x265_api_get
check_pkg_config libx265 x265 x265.h x265_api_get
test_pkg_config libx265 x265 x265.h x265_api_get
pkg-config --exists --print-errors x265
check_func_headers x265.h x265_api_get
-I/home/rdp/new/sandbox/win64_static/build_files/include
-L/home/rdp/new/sandbox/win64_static/build_files/lib -lx265
/usr/lib/gcc/x86_64-w64-mingw32/10-win32/libstdc++.a -lgcc
test_ld cc -I/home/rdp/new/sandbox/win64_static/build_files/include
-L/home/rdp/new/sandbox/win64_static/build_files/lib -lx265
/usr/lib/gcc/x86_64-w64-mingw32/10-win32/libstdc++.a -lgcc
test_cc -I/home/rdp/new/sandbox/win64_static/build_files/include
-L/home/rdp/new/sandbox/win64_static/build_files/lib
/usr/lib/gcc/x86_64-w64-mingw32/10-win32/libstdc++.a
BEGIN /tmp/ffconf.L9GhKESq/test.c
1 #include
2 #include
3 long check_x265_api_get(void) { return (long) x265_api_get; }
4 int main(void) { int ret = 0;
5ret |= ((intptr_t)check_x265_api_get) & 0x;
6 return ret; }
END /tmp/ffconf.L9GhKESq/test.c
x86_64-w64-mingw32-gcc -D_ISOC99_SOURCE -D_FILE_OFFSET_BITS=64
-D_LARGEFILE_SOURCE -U__STRICT_ANSI__ -D__USE_MINGW_ANSI_STDIO=1
-D__printf__=__gnu_printf__ -D_WIN32_WINNT=0x0600
-D_POSIX_C_SOURCE=200112 -D_XOPEN_SOURCE=600 -DPIC -std=c11
-fomit-frame-pointer
-I/home/rdp/new/sandbox/win64_static/build_files/include
-L/home/rdp/new/sandbox/win64_static/build_files/lib
/usr/lib/gcc/x86_64-w64-mingw32/10-win32/libstdc++.a -c -o
/tmp/ffconf.L9GhKESq/test.o /tmp/ffconf.L9GhKESq/test.c
/tmp/ffconf.L9GhKESq/test.c: In function 'check_x265_api_get':
/tmp/ffconf.L9GhKESq/test.c:3:40: warning: cast from pointer to
integer of different size [-Wpointer-to-int-cast]
3 | long check_x265_api_get(void) { return (long) x265_api_get; }
|^
x86_64-w64-mingw32-gcc: warning:
/usr/lib/gcc/x86_64-w64-mingw32/10-win32/libstdc++.a: linker input
file unused because linking not done
x86_64-w64-mingw32-gcc -Wl,--nxcompat,--dynamicbase
-Wl,--high-entropy-va -Wl,--as-needed -Wl,--image-base,0x14000
-I/home/rdp/new/sandbox/win64_static/build_files/include
-L/home/rdp/new/sandbox/win64_static/build_files/lib
/usr/lib/gcc/x86_64-w64-mingw32/10-win32/libstdc++.a -o
/tmp/ffconf.L9GhKESq/test.exe /tmp/ffconf.L9GhKESq/test.o -lx265 -lgcc
/usr/bin/x86_64-w64-mingw32-ld:
/home/rdp/new/sandbox/win64_static/build_files/lib/libx265.a(api.cpp.obj):api.cpp:(.text+0xfb5):
undefined reference to `operator new(unsigned long long)'
/usr/bin/x86_64-w64-mingw32-ld:
/home/rdp/new/sandbox/win64_static/build_files/lib/libx265.a(api.cpp.obj):api.cpp:(.text+0x1303):
undefined reference to `operator delete(void*)'
...
So it seems to be linking it not using the output of pkg-config --libs
--static for linking or something?
It's passing the pkg-config flags just fine.
The x265 .pc file is just broken and does not state its dependency on
libstdc++
x265.pc does list libstdc++
$ pkg-config --libs --static x265
-L/home/rdp/new/sandbox/win64_static/build_files/lib -lx265
/usr/lib/gcc/x86_64-w64-mingw32/10-win32/libstdc++.a -lgcc
I don't think that's a valid way to specify libs by absolute path.
At least configure doesn't think so, it specifically looks for stuff
starting with "-l" and discards the rest. Try adding -l: to the beginning.
When I configure ffmpeg I specify ./configure --pkg-config-flags=--static
But it appears to be rearranging the order when configure tries to use it?
x86_64-w64-mingw32-gcc: warning:
/usr/lib/gcc/x86_64-w64-mingw32/10-win32/libstdc++.a: linker input
file unused because linking not done
x86_64-w64-mingw32-gcc -Wl,--nxcompat,--dynamicbase
-Wl,--high-entropy-va -Wl,--as-needed -Wl,--image-base,0x14000
-I/home/rdp/new/sandbox/win64_static/build_files/include
-L/home/rdp/new/sandbox/win64_static/build_files/lib
/usr/lib/gcc/x86_64-w64-mingw32/10-win32/libstdc++.a -o
/tmp/ffconf.L9GhKESq/test.exe /tmp/ffconf.L9GhKESq/test.o -lx265 -lgcc
# THIS LINE has only x265 and lgcc
/usr/bin/x86_64-w64-mingw32-ld:
/home/rdp/new/sandbox/win64_static/build_files/lib/libx265.a(api.cpp.obj):api.cpp:(.text+0xfb5):
undefined reference to `operator new(unsigned long long)'
Possibly useful info:
$ pkg-config --libs x265
-L/home/rdp/new/sandbox/win64
[FFmpeg-devel] [PATCH 4/4] lavc/rv34dsp: R-V V rv34_idct_dc_add
From aec115a7179f23642c2b1c1a1cae3253a40c38fc Mon Sep 17 00:00:00 2001
From: sunyuechi
Date: Wed, 31 Jan 2024 19:04:11 +0800
Subject: [PATCH 4/4] lavc/rv34dsp: R-V V rv34_idct_dc_add
C908:
rv34_idct_dc_add_c: 134.7
rv34_idct_dc_add_rvv_i32: 45.5
---
libavcodec/riscv/rv34dsp_init.c | 2 ++
libavcodec/riscv/rv34dsp_rvv.S | 20
2 files changed, 22 insertions(+)
diff --git a/libavcodec/riscv/rv34dsp_init.c b/libavcodec/riscv/rv34dsp_init.c
index 852c8ad9a8..7dcadc7e43 100644
--- a/libavcodec/riscv/rv34dsp_init.c
+++ b/libavcodec/riscv/rv34dsp_init.c
@@ -26,6 +26,7 @@
#include "libavcodec/rv34dsp.h"
void ff_rv34_inv_transform_dc_rvv(int16_t *block);
+void ff_rv34_idct_dc_add_rvv(uint8_t *dst, ptrdiff_t stride, int dc);
av_cold void ff_rv34dsp_init_riscv(RV34DSPContext *c)
{
@@ -34,6 +35,7 @@ av_cold void ff_rv34dsp_init_riscv(RV34DSPContext *c)
if (flags & AV_CPU_FLAG_RVV_I32 && ff_get_rv_vlenb() >= 16) {
c->rv34_inv_transform_dc = ff_rv34_inv_transform_dc_rvv;
+c->rv34_idct_dc_add = ff_rv34_idct_dc_add_rvv;
}
#endif
}
diff --git a/libavcodec/riscv/rv34dsp_rvv.S b/libavcodec/riscv/rv34dsp_rvv.S
index acf5b0c3e8..c73b9c4555 100644
--- a/libavcodec/riscv/rv34dsp_rvv.S
+++ b/libavcodec/riscv/rv34dsp_rvv.S
@@ -36,3 +36,23 @@ func ff_rv34_inv_transform_dc_rvv, zve32x
ret
endfunc
+
+func ff_rv34_idct_dc_add_rvv, zve32x
+vsetivli zero, 4, e8, mf4, ta, ma
+vlse32.v v0, (a0), a1
+lit1, 169
+mulw t1, t1, a2
+lia2, 255
+addiw t1, t1, 512
+sraiw t1, t1, 10
+vsetivli zero, 4*4, e16, m2, ta, ma
+vzext.vf2 v2, v0
+vadd.vx v2, v2, t1
+vmax.vx v2, v2, zero
+vsetvli zero, zero, e8, m1, ta, ma
+vnclipu.wiv0, v2, 0
+vsetivli zero, 4, e8, mf4, ta, ma
+vsse32.v v0, (a0), a1
+
+ret
+endfunc
--
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 3/4] checkasm/rv34dsp: add rv34_idct_dc_add test
From 942fab5a2de6780c3b08c86fc457e9fbef3f9de3 Mon Sep 17 00:00:00 2001
From: sunyuechi
Date: Wed, 31 Jan 2024 19:01:25 +0800
Subject: [PATCH 3/4] checkasm/rv34dsp: add rv34_idct_dc_add test
---
tests/checkasm/rv34dsp.c | 24
1 file changed, 24 insertions(+)
diff --git a/tests/checkasm/rv34dsp.c b/tests/checkasm/rv34dsp.c
index 56167d2569..f4403b650f 100644
--- a/tests/checkasm/rv34dsp.c
+++ b/tests/checkasm/rv34dsp.c
@@ -56,10 +56,34 @@ static void test_rv34_inv_transform_dc(RV34DSPContext *s) {
report("rv34_inv_transform_dc");
}
+static void test_rv34_idct_dc_add_c(RV34DSPContext *s) {
+declare_func(void, uint8_t *dst, ptrdiff_t stride, int dc);
+
+if (check_func(s->rv34_idct_dc_add, "rv34_idct_dc_add")) {
+LOCAL_ALIGNED_16(uint8_t, p1, [BUF_SIZE]);
+LOCAL_ALIGNED_16(uint8_t, p2, [BUF_SIZE]);
+
+randomize(p1, BUF_SIZE);
+memcpy(p2, p1, BUF_SIZE * sizeof(*p1));
+
+call_ref(p1, 4, 5);
+call_new(p2, 4, 5);
+
+if (memcmp(p1, p2, BUF_SIZE * sizeof (*p1)) != 0) {
+fail();
+}
+
+bench_new(p1, 4, 5);
+}
+
+report("rv34_idct_dc_add");
+}
+
void checkasm_check_rv34dsp(void)
{
RV34DSPContext s = { 0 };
ff_rv34dsp_init(&s);
test_rv34_inv_transform_dc(&s);
+test_rv34_idct_dc_add_c(&s);
}
--
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/4] lavc/rv34dsp: R-V V rv34_inv_transform_dc
From 7e1c8d6b73afad9885222c0c9012543aface5397 Mon Sep 17 00:00:00 2001
From: sunyuechi
Date: Wed, 31 Jan 2024 19:03:20 +0800
Subject: [PATCH 2/4] lavc/rv34dsp: R-V V rv34_inv_transform_dc
C908:
rv34_inv_transform_dc_c: 35.5
rv34_inv_transform_dc_rvv_i32: 27.0
---
libavcodec/riscv/Makefile | 2 ++
libavcodec/riscv/rv34dsp_init.c | 39 +
libavcodec/riscv/rv34dsp_rvv.S | 38
libavcodec/rv34dsp.c| 2 ++
libavcodec/rv34dsp.h| 1 +
5 files changed, 82 insertions(+)
create mode 100644 libavcodec/riscv/rv34dsp_init.c
create mode 100644 libavcodec/riscv/rv34dsp_rvv.S
diff --git a/libavcodec/riscv/Makefile b/libavcodec/riscv/Makefile
index e15aba58f4..ffe6631cf2 100644
--- a/libavcodec/riscv/Makefile
+++ b/libavcodec/riscv/Makefile
@@ -44,6 +44,8 @@ RVV-OBJS-$(CONFIG_OPUS_DECODER) += riscv/opusdsp_rvv.o
OBJS-$(CONFIG_PIXBLOCKDSP) += riscv/pixblockdsp_init.o
RV-OBJS-$(CONFIG_PIXBLOCKDSP) += riscv/pixblockdsp_rvi.o
RVV-OBJS-$(CONFIG_PIXBLOCKDSP) += riscv/pixblockdsp_rvv.o
+OBJS-$(CONFIG_RV34DSP) += riscv/rv34dsp_init.o
+RVV-OBJS-$(CONFIG_RV34DSP) += riscv/rv34dsp_rvv.o
OBJS-$(CONFIG_SVQ1_ENCODER) += riscv/svqenc_init.o
RVV-OBJS-$(CONFIG_SVQ1_ENCODER) += riscv/svqenc_rvv.o
OBJS-$(CONFIG_TAK_DECODER) += riscv/takdsp_init.o
diff --git a/libavcodec/riscv/rv34dsp_init.c b/libavcodec/riscv/rv34dsp_init.c
new file mode 100644
index 00..852c8ad9a8
--- /dev/null
+++ b/libavcodec/riscv/rv34dsp_init.c
@@ -0,0 +1,39 @@
+/*
+ * Copyright (c) 2024 Institue of Software Chinese Academy of Sciences (ISCAS).
+ *
+ * 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 "config.h"
+
+#include "libavutil/attributes.h"
+#include "libavutil/cpu.h"
+#include "libavutil/riscv/cpu.h"
+#include "libavcodec/rv34dsp.h"
+
+void ff_rv34_inv_transform_dc_rvv(int16_t *block);
+
+av_cold void ff_rv34dsp_init_riscv(RV34DSPContext *c)
+{
+#if HAVE_RVV
+int flags = av_get_cpu_flags();
+
+if (flags & AV_CPU_FLAG_RVV_I32 && ff_get_rv_vlenb() >= 16) {
+c->rv34_inv_transform_dc = ff_rv34_inv_transform_dc_rvv;
+}
+#endif
+}
diff --git a/libavcodec/riscv/rv34dsp_rvv.S b/libavcodec/riscv/rv34dsp_rvv.S
new file mode 100644
index 00..acf5b0c3e8
--- /dev/null
+++ b/libavcodec/riscv/rv34dsp_rvv.S
@@ -0,0 +1,38 @@
+/*
+ * Copyright (c) 2024 Institue of Software Chinese Academy of Sciences (ISCAS).
+ *
+ * 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/riscv/asm.S"
+
+func ff_rv34_inv_transform_dc_rvv, zve32x
+lht1, 0(a0)
+slliw t2, t1, 7
+subw t2, t2, t1
+slliw t2, t2, 2
+subw t2, t2, t1
+sraiw t2, t2, 11
+slliw t2, t2, 16
+sraiw t2, t2, 16
+vsetivli zero, 16, e16, m2, ta, ma
+vmv.v.x v8, t2
+vsetivli zero, 4, e8, mf4, ta, ma
+vse64.v v8, (a0)
+
+ret
+endfunc
diff --git a/libavcodec/rv34dsp.c b/libavcodec/rv34dsp.c
index 8f9d88396c..44486f8edd 100644
--- a/libavcodec/rv34dsp.c
+++ b/libavcodec/rv34dsp.c
@@ -138,6 +138,8 @@ av_cold void ff_rv34dsp_init(RV34DSPContext *c)
#if ARCH_ARM
ff_rv34dsp_init_arm(c);
+#elif ARCH_RISCV
+ff_rv34dsp_init_riscv(c);
#elif ARCH_X86
ff_rv34dsp_init_x86(c);
#endif
diff --git a/libavcodec/rv34dsp.h b/libavcodec/rv34dsp.h
index 2e9ec4eee4..b15424d4ae 100644
--- a/libavcodec/rv34dsp.h
+++ b/libavcodec/rv34dsp.h
@@ -79,6 +79,7 @@ vo
[FFmpeg-devel] [PATCH 1/4] checkasm/rv34dsp: add rv34_inv_transform_dc test
From 46a81051f49f6b4032815d5f123be8ff614033e2 Mon Sep 17 00:00:00 2001
From: sunyuechi
Date: Wed, 31 Jan 2024 19:00:23 +0800
Subject: [PATCH 1/4] checkasm/rv34dsp: add rv34_inv_transform_dc test
---
tests/checkasm/Makefile | 1 +
tests/checkasm/checkasm.c | 3 ++
tests/checkasm/checkasm.h | 1 +
tests/checkasm/rv34dsp.c | 65 +++
tests/fate/checkasm.mak | 1 +
5 files changed, 71 insertions(+)
create mode 100644 tests/checkasm/rv34dsp.c
diff --git a/tests/checkasm/Makefile b/tests/checkasm/Makefile
index f507e3..e4c1ff7d79 100644
--- a/tests/checkasm/Makefile
+++ b/tests/checkasm/Makefile
@@ -34,6 +34,7 @@ AVCODECOBJS-$(CONFIG_JPEG2000_DECODER) += jpeg2000dsp.o
AVCODECOBJS-$(CONFIG_OPUS_DECODER) += opusdsp.o
AVCODECOBJS-$(CONFIG_PIXBLOCKDSP) += pixblockdsp.o
AVCODECOBJS-$(CONFIG_HEVC_DECODER) += hevc_add_res.o hevc_deblock.o hevc_idct.o hevc_sao.o hevc_pel.o
+AVCODECOBJS-$(CONFIG_RV34DSP) += rv34dsp.o
AVCODECOBJS-$(CONFIG_SVQ1_ENCODER) += svq1enc.o
AVCODECOBJS-$(CONFIG_TAK_DECODER) += takdsp.o
AVCODECOBJS-$(CONFIG_UTVIDEO_DECODER) += utvideodsp.o
diff --git a/tests/checkasm/checkasm.c b/tests/checkasm/checkasm.c
index ed9f7f3d7b..ed9bd5e248 100644
--- a/tests/checkasm/checkasm.c
+++ b/tests/checkasm/checkasm.c
@@ -167,6 +167,9 @@ static const struct {
#if CONFIG_PIXBLOCKDSP
{ "pixblockdsp", checkasm_check_pixblockdsp },
#endif
+#if CONFIG_RV34DSP
+{ "rv34dsp", checkasm_check_rv34dsp },
+#endif
#if CONFIG_SVQ1_ENCODER
{ "svq1enc", checkasm_check_svq1enc },
#endif
diff --git a/tests/checkasm/checkasm.h b/tests/checkasm/checkasm.h
index bb74c0cc4b..1022bbbac7 100644
--- a/tests/checkasm/checkasm.h
+++ b/tests/checkasm/checkasm.h
@@ -112,6 +112,7 @@ void checkasm_check_nlmeans(void);
void checkasm_check_opusdsp(void);
void checkasm_check_pixblockdsp(void);
void checkasm_check_sbrdsp(void);
+void checkasm_check_rv34dsp(void);
void checkasm_check_svq1enc(void);
void checkasm_check_synth_filter(void);
void checkasm_check_sw_gbrp(void);
diff --git a/tests/checkasm/rv34dsp.c b/tests/checkasm/rv34dsp.c
new file mode 100644
index 00..56167d2569
--- /dev/null
+++ b/tests/checkasm/rv34dsp.c
@@ -0,0 +1,65 @@
+/*
+ * Copyright (c) 2024 Institue of Software Chinese Academy of Sciences (ISCAS).
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 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 General Public License for more details.
+ *
+ * You should have received a copy of the GNU 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/mem.h"
+#include "libavutil/mem_internal.h"
+
+#include "libavcodec/rv34dsp.h"
+
+#include "checkasm.h"
+
+#define BUF_SIZE 1024
+
+#define randomize(buf, len) \
+do { \
+for (int i = 0; i < len; i++) \
+buf[i] = rnd(); \
+} while (0)
+
+static void test_rv34_inv_transform_dc(RV34DSPContext *s) {
+declare_func(void, int16_t *block);
+
+if (check_func(s->rv34_inv_transform_dc, "rv34_inv_transform_dc")) {
+LOCAL_ALIGNED_16(int16_t, p1, [BUF_SIZE]);
+LOCAL_ALIGNED_16(int16_t, p2, [BUF_SIZE]);
+
+randomize(p1, BUF_SIZE);
+memcpy(p2, p1, BUF_SIZE * sizeof(*p1));
+
+call_ref(p1);
+call_new(p2);
+
+if (memcmp(p1, p2, BUF_SIZE * sizeof (*p1)) != 0) {
+fail();
+}
+
+bench_new(p1);
+}
+
+report("rv34_inv_transform_dc");
+}
+
+void checkasm_check_rv34dsp(void)
+{
+RV34DSPContext s = { 0 };
+ff_rv34dsp_init(&s);
+
+test_rv34_inv_transform_dc(&s);
+}
diff --git a/tests/fate/checkasm.mak b/tests/fate/checkasm.mak
index 3d775549ee..086493c4bd 100644
--- a/tests/fate/checkasm.mak
+++ b/tests/fate/checkasm.mak
@@ -34,6 +34,7 @@ FATE_CHECKASM = fate-checkasm-aacencdsp \
fate-checkasm-opusdsp \
fate-checkasm-pixblockdsp \
fate-checkasm-sbrdsp\
+fate-checkasm-rv34dsp \
fate-checkasm-svq1enc \
fate-checkasm-synth_filter \
fate-checkasm-sw_gbrp \
--
2.43.0
___
ffmp
Re: [FFmpeg-devel] [PATCH 1/2] avfilter: pass link YUV colorspace to ff_draw_init2
On Wed, Jan 31, 2024 at 12:17 PM Niklas Haas wrote: > > From: Niklas Haas > > diff --git a/libavfilter/vf_drawtext.c b/libavfilter/vf_drawtext.c > index fe7e6ace27..37110bc32f 100644 > --- a/libavfilter/vf_drawtext.c > +++ b/libavfilter/vf_drawtext.c > @@ -1152,7 +1152,7 @@ static int config_input(AVFilterLink *inlink) > char *expr; > int ret; > > -ff_draw_init(&s->dc, inlink->format, FF_DRAW_PROCESS_ALPHA); > +ff_draw_init(&s->dc, inlink->format, inlink->colorspace, > inlink->color_range, FF_DRAW_PROCESS_ALPHA); Should this be ff_draw_init2? > ff_draw_color(&s->dc, &s->fontcolor, s->fontcolor.rgba); > ff_draw_color(&s->dc, &s->shadowcolor, s->shadowcolor.rgba); > ff_draw_color(&s->dc, &s->bordercolor, s->bordercolor.rgba); ___ 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] avcodec/dxva2: fix different 'const' qualifiers warning
From: Tong Wu Signed-off-by: Tong Wu --- libavcodec/dxva2.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libavcodec/dxva2.c b/libavcodec/dxva2.c index ec0d9e7d1c..59025633f7 100644 --- a/libavcodec/dxva2.c +++ b/libavcodec/dxva2.c @@ -795,7 +795,7 @@ unsigned ff_dxva2_get_surface_index(const AVCodecContext *avctx, } #endif -av_log(avctx, AV_LOG_WARNING, "Could not get surface index. Using 0 instead.\n"); +av_log((AVCodecContext *)avctx, AV_LOG_WARNING, "Could not get surface index. Using 0 instead.\n"); return 0; } -- 2.43.0.windows.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 1/2] avcodec/d3d12va_decode: fix different 'const' qualifiers warning
From: Tong Wu Signed-off-by: Tong Wu --- libavcodec/d3d12va_decode.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libavcodec/d3d12va_decode.c b/libavcodec/d3d12va_decode.c index f678b6f483..a615a3898b 100644 --- a/libavcodec/d3d12va_decode.c +++ b/libavcodec/d3d12va_decode.c @@ -79,7 +79,7 @@ unsigned ff_d3d12va_get_surface_index(const AVCodecContext *avctx, } fail: -av_log(avctx, AV_LOG_WARNING, "Could not get surface index. Using 0 instead.\n"); +av_log((AVCodecContext *)avctx, AV_LOG_WARNING, "Could not get surface index. Using 0 instead.\n"); return 0; } -- 2.43.0.windows.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] avcodec/d3d12va_vc1: add support for D3D12_VIDEO_DECODE_PROFILE_VC1_D2010 guid.
From: Aleksoid
The VC1_D2010 profile, also known as VC1_VLD2010, has the same functionality
and specification as the VC1_D profile. Support for this profile serves only
as a positive indication that the accelerator has been designed with awareness
of the modifications specified in the August 2010 version of this specification.
Hardware accelerator drivers that expose support for this profile must not
also expose the previously specified VC1_D GUID, unless the accelerator works
properly with existing software decoders that use VC1_D and that do not
incorporate
the corrections added to the August 2010 version of this specification.
As a result, we could give VC1_VLD2010 a higher priority and initialize
it first.
Signed-off-by: Aleksoid
Signed-off-by: Tong Wu
---
libavcodec/d3d12va_vc1.c | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/libavcodec/d3d12va_vc1.c b/libavcodec/d3d12va_vc1.c
index 3aa2743107..110926be82 100644
--- a/libavcodec/d3d12va_vc1.c
+++ b/libavcodec/d3d12va_vc1.c
@@ -164,12 +164,19 @@ static int d3d12va_vc1_end_frame(AVCodecContext *avctx)
static int d3d12va_vc1_decode_init(AVCodecContext *avctx)
{
+int ret;
D3D12VADecodeContext *ctx = D3D12VA_DECODE_CONTEXT(avctx);
-ctx->cfg.DecodeProfile = D3D12_VIDEO_DECODE_PROFILE_VC1;
+ctx->cfg.DecodeProfile = D3D12_VIDEO_DECODE_PROFILE_VC1_D2010;
ctx->max_num_ref = 3;
-return ff_d3d12va_decode_init(avctx);
+ret = ff_d3d12va_decode_init(avctx);
+if (ret < 0) {
+ctx->cfg.DecodeProfile = D3D12_VIDEO_DECODE_PROFILE_VC1;
+ret = ff_d3d12va_decode_init(avctx);
+}
+
+return ret;
}
#if CONFIG_WMV3_D3D12VA_HWACCEL
--
2.43.0.windows.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] Sovereign Tech Fund
Quoting Michael Niedermayer (2024-01-29 22:27:07) > Hi > > On Mon, Jan 29, 2024 at 09:36:27PM +0100, Vittorio Giovara wrote: > > On Mon, Jan 29, 2024 at 9:19 PM Anton Khirnov wrote: > > > > > Quoting Vittorio Giovara (2024-01-29 21:09:42) > > > > This is not something that should be discussed on a public ML > > > > > > Where do you think it should be discussed then? > > > > > > > IMO anywhere with a more limited set of constituents, such as the GA or the > > technical committee. > > For the record, the group that was contacted initially by STF was everyone > on the consulting page at the time. > > This probably made sense to STF as they after all wanted to fund people > working. And that page would supposedly list everyone who was available > to do work. > > From there on mainly only one person cared and continued to work on this. > For the record, the list of people on the CC also evolved over time, > one from STF was added, some people seemingly having no interrest disappeared > multiple people related to SPI where added. > > I guess i understand why noone wanted to send this to the ML and i had to ... > > seriously, i dont think anyone had any bad intend here. Yes i wanted it > on the ML long ago and others wanted to first make sure this was real and > actually possible. This ended up being 2 weeks before the next STF meeting > but really everyone just tried to do what they thought best for FFmpeg Who are these 'others' (plural) you speak of? And why did they think they have the right to unilaterally nominate themselves as community representatives? And - since you apparently announced this against their wishes with only a little time to spare - what did they intend to do with the application instead? Submit it without community approval? And why are you defending them instead of them speaking for themselves? It is quite hard not to see this as someone's attempt to strongarm the project into their preferred course of action. -- 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] [FFmpeg-cvslog] vf_scale: use colorspace negotiation API
On Tue, 30 Jan 2024 23:36:37 +0100 Michael Niedermayer wrote: > On Mon, Jan 29, 2024 at 07:49:49PM +0100, Niklas Haas wrote: > > On Mon, 29 Jan 2024 04:19:43 +0100 Michael Niedermayer > > wrote: > > > On Sun, Dec 31, 2023 at 09:49:47PM +, Niklas Haas wrote: > > > > ffmpeg | branch: master | Niklas Haas | Tue Oct 31 > > > > 13:52:53 2023 +0100| [45e09a30419cc2a7251e72689142e021ecdfe6d9] | > > > > committer: Niklas Haas > > > > > > > > vf_scale: use colorspace negotiation API > > > > > > > > This filter will always accept any input format, even if the user sets > > > > a specific in_range/in_color_matrix. This is to preserve status quo with > > > > current behavior, where passing a specific in_color_matrix merely > > > > overrides the incoming frames' attributes. (Use `vf_format` to force > > > > a specific input range) > > > > > > > > Because changing colorspace and color_range now requires reconfiguring > > > > the link, we can lift sws_setColorspaceDetails out of scale_frame and > > > > into config_props. (This will also get re-called if the input frame > > > > properties change) > > > > > > > > > http://git.videolan.org/gitweb.cgi/ffmpeg.git/?a=commit;h=45e09a30419cc2a7251e72689142e021ecdfe6d9 > > > > --- > > > > > > > > libavfilter/vf_scale.c | 188 > > > > +++-- > > > > 1 file changed, 103 insertions(+), 85 deletions(-) > > > > > > This seems to remove metadata > > > > > > ./ffmpeg -f lavfi -i color=black -pix_fmt yuv422p10le -bitexact -vframes > > > 1 -f framecrc - > > > > > > Stream #0:0: Video: rawvideo (Y3[10][10] / 0xA0A3359), yuv422p10le(tv, > > > progressive), 320x240 [SAR 1:1 DAR 4:3], q=2-31, 38400 kb/s, 25 fps, 25 > > > tbn > > > vs > > > Stream #0:0: Video: rawvideo (Y3[10][10] / 0xA0A3359), > > > yuv422p10le(progressive), 320x240 [SAR 1:1 DAR 4:3], q=2-31, 38400 kb/s, > > > 25 fps, 25 tbn > > > > > > > > > when its stored in a file, it results in a different output, example: > > > ./ffmpeg -f lavfi -i color=black -pix_fmt yuv422p10le -bitexact -vframes > > > 1 -c:v ffv1 -level 3 -y ffv1-lavf-black-4636-new.mkv > > > > > > > > > I have not investigated what is correct, but i would think "no range > > > information" > > > would seem worse than whatever the correct is > > > > Looking at this quickly, what is happening here is not that vf_scale is > > stripping metadata, it's that vf_scale used to *add* default metadata after > > a pixel format conversion - even though it did not touch the pixel > > range, and the incoming frames were untagged. This was arguably a bug. > > The new behavior is actually less surprising here - the vsrc generates > > untagged frames, so vf_scale preserves them being untagged. > > > > (Observe -vf showinfo,format=yuv422p10le,showinfo before vs after patch) > > > > In any case, the *proper* fix here would be to make vsrc_testsrc aware > > of the colorspace negotiation API. Ideally, it should switch from > > ff_draw_init to ff_draw_init2, and use the negotiated YUV colorspace and > > range. (pal(75|100)bars are also bugged) > > Thanks alot for analyzing, ive added a note locally so if i run into another > case ill remember > > I dont have time ATM to fix vsrc_testsrc Sent two patches to fix all of the issues I saw with vsrc_testsrc (and some other ff_draw_init() callers) The status quo of outputting *untagged* limited range YUV by default persists, as this was an intentional design choice, and it's consistent with the status quo. That said, it would be trivial to change. ___ 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] avfilter: pass link YUV colorspace to ff_draw_init2
From: Niklas Haas
This makes all ff_draw_* based filters aware of YUV colorspaces and
ranges. Needed for YUVJ removal. Also fixes a bug where e.g. vf_pad
would generate a limited range background even after conversion to
full-scale grayscale.
The FATE changes were a consequence of the aforementioned bugfix - the
gray scale files are output as full range (due to conversion by
libswscale, which hard-codes gray = full), and appropriately tagged as
such, but before this change the padded version incorrectly used
a limited range (16) black background for these formats.
---
libavfilter/qrencode.c| 8 +---
libavfilter/src_avsynctest.c | 2 +-
libavfilter/vf_datascope.c| 2 +-
libavfilter/vf_drawtext.c | 2 +-
libavfilter/vf_pad.c | 2 +-
libavfilter/vf_rotate.c | 2 +-
libavfilter/vf_shear.c| 2 +-
libavfilter/vf_stack.c| 3 ++-
libavfilter/vf_subtitles.c| 3 ++-
libavfilter/vf_tile.c | 2 +-
libavfilter/vf_tinterlace.c | 2 +-
libavfilter/vf_tpad.c | 2 +-
libavfilter/vsrc_testsrc.c| 9 ++---
tests/ref/fate/filter-pixfmts-pad | 16
14 files changed, 32 insertions(+), 25 deletions(-)
diff --git a/libavfilter/qrencode.c b/libavfilter/qrencode.c
index 09af8dfb4e..6b86e01f57 100644
--- a/libavfilter/qrencode.c
+++ b/libavfilter/qrencode.c
@@ -638,7 +638,7 @@ static int qrencodesrc_config_props(AVFilterLink *outlink)
ff_draw_color(&qr->draw, &qr->draw_foreground_color, (const uint8_t
*)&qr->foreground_color);
ff_draw_color(&qr->draw, &qr->draw_background_color, (const uint8_t
*)&qr->background_color);
-ff_draw_init(&qr->draw0, outlink->format, FF_DRAW_PROCESS_ALPHA);
+ff_draw_init2(&qr->draw0, outlink->format, outlink->colorspace,
outlink->color_range, FF_DRAW_PROCESS_ALPHA);
ff_draw_color(&qr->draw0, &qr->draw0_background_color, (const uint8_t
*)&qr->background_color);
outlink->w = qr->rendered_padded_qrcode_width;
@@ -730,7 +730,8 @@ static int qrencode_config_input(AVFilterLink *inlink)
qr->is_source = 0;
-ff_draw_init(&qr->draw, inlink->format, FF_DRAW_PROCESS_ALPHA);
+ff_draw_init2(&qr->draw, inlink->format, inlink->colorspace,
inlink->color_range,
+ FF_DRAW_PROCESS_ALPHA);
V(W) = V(main_w) = inlink->w;
V(H) = V(main_h) = inlink->h;
@@ -759,7 +760,8 @@ static int qrencode_config_input(AVFilterLink *inlink)
PARSE_EXPR(rendered_qrcode_width);
PARSE_EXPR(rendered_padded_qrcode_width);
-ff_draw_init(&qr->draw, inlink->format, FF_DRAW_PROCESS_ALPHA);
+ff_draw_init2(&qr->draw, inlink->format, inlink->colorspace,
inlink->color_range,
+ FF_DRAW_PROCESS_ALPHA);
ff_draw_color(&qr->draw, &qr->draw_foreground_color, (const uint8_t
*)&qr->foreground_color);
ff_draw_color(&qr->draw, &qr->draw_background_color, (const uint8_t
*)&qr->background_color);
diff --git a/libavfilter/src_avsynctest.c b/libavfilter/src_avsynctest.c
index a0fef7a1cb..9fd0b590c1 100644
--- a/libavfilter/src_avsynctest.c
+++ b/libavfilter/src_avsynctest.c
@@ -160,7 +160,7 @@ static av_cold int config_props(AVFilterLink *outlink)
s->dir = 1;
s->prev_intpart = INT64_MIN;
-ff_draw_init(&s->draw, outlink->format, 0);
+ff_draw_init2(&s->draw, outlink->format, outlink->colorspace,
outlink->color_range, 0);
ff_draw_color(&s->draw, &s->fg, s->rgba[0]);
ff_draw_color(&s->draw, &s->bg, s->rgba[1]);
diff --git a/libavfilter/vf_datascope.c b/libavfilter/vf_datascope.c
index 89b59f2510..4845c9918d 100644
--- a/libavfilter/vf_datascope.c
+++ b/libavfilter/vf_datascope.c
@@ -383,7 +383,7 @@ static int config_input(AVFilterLink *inlink)
uint8_t alpha = s->opacity * 255;
s->nb_planes = av_pix_fmt_count_planes(inlink->format);
-ff_draw_init(&s->draw, inlink->format, 0);
+ff_draw_init2(&s->draw, inlink->format, inlink->colorspace,
inlink->color_range, 0);
ff_draw_color(&s->draw, &s->white, (uint8_t[]){ 255, 255, 255, 255} );
ff_draw_color(&s->draw, &s->black, (uint8_t[]){ 0, 0, 0, alpha} );
ff_draw_color(&s->draw, &s->yellow, (uint8_t[]){ 255, 255, 0, 255} );
diff --git a/libavfilter/vf_drawtext.c b/libavfilter/vf_drawtext.c
index fe7e6ace27..37110bc32f 100644
--- a/libavfilter/vf_drawtext.c
+++ b/libavfilter/vf_drawtext.c
@@ -1152,7 +1152,7 @@ static int config_input(AVFilterLink *inlink)
char *expr;
int ret;
-ff_draw_init(&s->dc, inlink->format, FF_DRAW_PROCESS_ALPHA);
+ff_draw_init(&s->dc, inlink->format, inlink->colorspace,
inlink->color_range, FF_DRAW_PROCESS_ALPHA);
ff_draw_color(&s->dc, &s->fontcolor, s->fontcolor.rgba);
ff_draw_color(&s->dc, &s->shadowcolor, s->shadowcolor.rgba);
ff_draw_color(&s->dc, &s->bordercolor, s->bordercolor.rgba);
diff --git a/libavfilter/vf_pad.c b/libavfilter/vf_pad.c
index e52f7284d4..240b6b929d 100644
--- a/libavfilter/vf_pad.c
+++
[FFmpeg-devel] [PATCH 2/2] avfilter/vsrc_testsrc: switch to YUV colorspace negotiation API
From: Niklas Haas
Instead of overriding the frame properties in fill_picture(), advertise
the supported YUV colorspace and range at format negotiation time. (The
correct metadata will now be set automatically by ff_get_video_buffer)
---
libavfilter/vsrc_testsrc.c | 47 +-
1 file changed, 31 insertions(+), 16 deletions(-)
diff --git a/libavfilter/vsrc_testsrc.c b/libavfilter/vsrc_testsrc.c
index 73a61bfa45..c51ba46c97 100644
--- a/libavfilter/vsrc_testsrc.c
+++ b/libavfilter/vsrc_testsrc.c
@@ -1418,6 +1418,24 @@ static const enum AVPixelFormat smptebars_pix_fmts[] = {
AV_PIX_FMT_NONE,
};
+static int smptebars_query_formats(AVFilterContext *ctx)
+{
+enum AVColorSpace csp;
+int ret;
+
+if (!strcmp(ctx->name, "smptehdbars")) {
+csp = AVCOL_SPC_BT709;
+} else {
+csp = AVCOL_SPC_BT470BG;
+}
+
+if ((ret = ff_set_common_color_spaces(ctx,
ff_make_formats_list_singleton(csp
+return ret;
+if ((ret = ff_set_common_color_ranges(ctx,
ff_make_formats_list_singleton(AVCOL_RANGE_MPEG
+return ret;
+return ff_set_common_formats_from_list(ctx, smptebars_pix_fmts);
+}
+
AVFILTER_DEFINE_CLASS_EXT(palbars, "pal(75|100)bars", options);
#if CONFIG_PAL75BARS_FILTER
@@ -1428,9 +1446,6 @@ static void pal75bars_fill_picture(AVFilterContext *ctx,
AVFrame *picref)
int r_w, i, x = 0;
const AVPixFmtDescriptor *pixdesc = av_pix_fmt_desc_get(picref->format);
-picref->color_range = AVCOL_RANGE_MPEG;
-picref->colorspace = AVCOL_SPC_BT470BG;
-
r_w = FFALIGN((test->w + 7) / 8, 1 << pixdesc->log2_chroma_w);
draw_bar(test, white, x, 0, r_w, test->h, picref);
@@ -1461,7 +1476,7 @@ const AVFilter ff_vsrc_pal75bars = {
.activate = activate,
.inputs= NULL,
FILTER_OUTPUTS(outputs),
-FILTER_PIXFMTS_ARRAY(smptebars_pix_fmts),
+FILTER_QUERY_FUNC(smptebars_query_formats),
};
#endif /* CONFIG_PAL75BARS_FILTER */
@@ -1474,9 +1489,6 @@ static void pal100bars_fill_picture(AVFilterContext *ctx,
AVFrame *picref)
int r_w, i, x = 0;
const AVPixFmtDescriptor *pixdesc = av_pix_fmt_desc_get(picref->format);
-picref->color_range = AVCOL_RANGE_MPEG;
-picref->colorspace = AVCOL_SPC_BT470BG;
-
r_w = FFALIGN((test->w + 7) / 8, 1 << pixdesc->log2_chroma_w);
for (i = 0; i < 7; i++) {
@@ -1505,7 +1517,7 @@ const AVFilter ff_vsrc_pal100bars = {
.activate = activate,
.inputs= NULL,
FILTER_OUTPUTS(outputs),
-FILTER_PIXFMTS_ARRAY(smptebars_pix_fmts),
+FILTER_QUERY_FUNC(smptebars_query_formats),
};
#endif /* CONFIG_PAL100BARS_FILTER */
@@ -1520,8 +1532,6 @@ static void smptebars_fill_picture(AVFilterContext *ctx,
AVFrame *picref)
int r_w, r_h, w_h, p_w, p_h, i, tmp, x = 0;
const AVPixFmtDescriptor *pixdesc = av_pix_fmt_desc_get(picref->format);
-picref->colorspace = AVCOL_SPC_BT470BG;
-
r_w = FFALIGN((test->w + 6) / 7, 1 << pixdesc->log2_chroma_w);
r_h = FFALIGN(test->h * 2 / 3, 1 << pixdesc->log2_chroma_h);
w_h = FFALIGN(test->h * 3 / 4 - r_h, 1 << pixdesc->log2_chroma_h);
@@ -1572,7 +1582,7 @@ const AVFilter ff_vsrc_smptebars = {
.activate = activate,
.inputs= NULL,
FILTER_OUTPUTS(outputs),
-FILTER_PIXFMTS_ARRAY(smptebars_pix_fmts),
+FILTER_QUERY_FUNC(smptebars_query_formats),
};
#endif /* CONFIG_SMPTEBARS_FILTER */
@@ -1585,8 +1595,6 @@ static void smptehdbars_fill_picture(AVFilterContext
*ctx, AVFrame *picref)
int d_w, r_w, r_h, l_w, i, tmp, x = 0, y = 0;
const AVPixFmtDescriptor *pixdesc = av_pix_fmt_desc_get(picref->format);
-picref->colorspace = AVCOL_SPC_BT709;
-
d_w = FFALIGN(test->w / 8, 1 << pixdesc->log2_chroma_w);
r_h = FFALIGN(test->h * 7 / 12, 1 << pixdesc->log2_chroma_h);
draw_bar(test, gray40, x, 0, d_w, r_h, picref);
@@ -1675,7 +1683,7 @@ const AVFilter ff_vsrc_smptehdbars = {
.activate = activate,
.inputs= NULL,
FILTER_OUTPUTS(outputs),
-FILTER_PIXFMTS_ARRAY(smptebars_pix_fmts),
+FILTER_QUERY_FUNC(smptebars_query_formats),
};
#endif /* CONFIG_SMPTEHDBARS_FILTER */
@@ -2138,7 +2146,6 @@ ZONEPLATE_SLICE(16, uint16_t)
static void zoneplate_fill_picture(AVFilterContext *ctx, AVFrame *frame)
{
TestSourceContext *test = ctx->priv;
-frame->color_range = AVCOL_RANGE_JPEG;
ff_filter_execute(ctx, test->fill_slice_fn, frame, NULL,
FFMIN(frame->height, ff_filter_get_nb_threads(ctx)));
}
@@ -2194,6 +2201,14 @@ static const enum AVPixelFormat zoneplate_pix_fmts[] = {
AV_PIX_FMT_NONE,
};
+static int zoneplate_query_formats(AVFilterContext *ctx)
+{
+int ret;
+if ((ret = ff_set_common_color_ranges(ctx,
ff_make_formats_list_singleton(AVCOL_RANGE_JPEG
+return ret;
+return ff_set_common_formats_from_list(ctx, zoneplate_pix_fmts);
+}
+
static const AVFilterPad avfilter_vsrc_zoneplate_outputs[] =
Re: [FFmpeg-devel] [PATCH] flv: fix stereo flag when writing PCMA/PCMU
Hello again, i'm bumping this patch since currently it's impossible to stream 16khz or stereo G711 tracks with RTMP, as these are always marked as 8khz, mono tracks. Please consider merging. Thanks. Il giorno dom 21 gen 2024 alle ore 16:16 Alessandro Ros ha scritto: > Currently, when writing PCMA or PCMU tracks with FLV or RTMP, the > stereo flag and sample rate flag inside RTMP audio messages are > overridden, making impossible to distinguish between mono and stereo > tracks. This patch fixes the issue by restoring the same flag mechanism > of all other codecs, that takes into consideration the right channel > count and sample rate. > > Signed-off-by: Alessandro Ros > --- > libavformat/flvenc.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/libavformat/flvenc.c b/libavformat/flvenc.c > index 874560fac1..772d891136 100644 > --- a/libavformat/flvenc.c > +++ b/libavformat/flvenc.c > @@ -208,10 +208,10 @@ error: > flags |= FLV_CODECID_NELLYMOSER| > FLV_SAMPLESSIZE_16BIT; > break; > case AV_CODEC_ID_PCM_MULAW: > -flags = FLV_CODECID_PCM_MULAW | FLV_SAMPLERATE_SPECIAL | > FLV_SAMPLESSIZE_16BIT; > +flags |= FLV_CODECID_PCM_MULAW | FLV_SAMPLESSIZE_16BIT; > break; > case AV_CODEC_ID_PCM_ALAW: > -flags = FLV_CODECID_PCM_ALAW | FLV_SAMPLERATE_SPECIAL | > FLV_SAMPLESSIZE_16BIT; > +flags |= FLV_CODECID_PCM_ALAW | FLV_SAMPLESSIZE_16BIT; > break; > case 0: > flags |= par->codec_tag << 4; > -- > 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".
[FFmpeg-devel] [PATCH 3/3] avformat/iamf*: Improve included headers
Signed-off-by: Andreas Rheinhardt --- libavformat/iamf.h| 2 +- libavformat/iamf_parse.h | 1 - libavformat/iamf_writer.c | 2 -- libavformat/iamf_writer.h | 3 +-- libavformat/iamfdec.c | 3 --- libavformat/iamfenc.c | 1 - 6 files changed, 2 insertions(+), 10 deletions(-) diff --git a/libavformat/iamf.h b/libavformat/iamf.h index ce94cb5bc4..d88a24c435 100644 --- a/libavformat/iamf.h +++ b/libavformat/iamf.h @@ -22,13 +22,13 @@ #ifndef AVFORMAT_IAMF_H #define AVFORMAT_IAMF_H +#include #include #include "libavutil/channel_layout.h" #include "libavutil/iamf.h" #include "libavcodec/codec_id.h" #include "libavcodec/codec_par.h" -#include "avformat.h" #define MAX_IAMF_OBU_HEADER_SIZE (1 + 8 * 3) diff --git a/libavformat/iamf_parse.h b/libavformat/iamf_parse.h index f4f297ecd4..bb506486d7 100644 --- a/libavformat/iamf_parse.h +++ b/libavformat/iamf_parse.h @@ -24,7 +24,6 @@ #include -#include "libavutil/iamf.h" #include "avio.h" #include "iamf.h" diff --git a/libavformat/iamf_writer.c b/libavformat/iamf_writer.c index 5850c53c8e..1a360dee2f 100644 --- a/libavformat/iamf_writer.c +++ b/libavformat/iamf_writer.c @@ -24,8 +24,6 @@ #include "libavutil/iamf.h" #include "libavutil/mem.h" #include "libavcodec/get_bits.h" -#include "libavcodec/flac.h" -#include "libavcodec/mpeg4audio.h" #include "libavcodec/put_bits.h" #include "avformat.h" #include "avio_internal.h" diff --git a/libavformat/iamf_writer.h b/libavformat/iamf_writer.h index 93354670b8..24f1c14769 100644 --- a/libavformat/iamf_writer.h +++ b/libavformat/iamf_writer.h @@ -22,9 +22,8 @@ #ifndef AVFORMAT_IAMF_WRITER_H #define AVFORMAT_IAMF_WRITER_H -#include +#include -#include "libavutil/common.h" #include "avformat.h" #include "avio.h" #include "iamf.h" diff --git a/libavformat/iamfdec.c b/libavformat/iamfdec.c index 3b8d2ff358..99622f697b 100644 --- a/libavformat/iamfdec.c +++ b/libavformat/iamfdec.c @@ -19,8 +19,6 @@ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA */ -#include "config_components.h" - #include "libavutil/avassert.h" #include "libavutil/iamf.h" #include "libavutil/intreadwrite.h" @@ -28,7 +26,6 @@ #include "libavcodec/mathops.h" #include "avformat.h" #include "avio_internal.h" -#include "demux.h" #include "iamf.h" #include "iamf_parse.h" #include "internal.h" diff --git a/libavformat/iamfenc.c b/libavformat/iamfenc.c index e1003d5495..b588a507bb 100644 --- a/libavformat/iamfenc.c +++ b/libavformat/iamfenc.c @@ -24,7 +24,6 @@ #include "libavutil/avassert.h" #include "libavutil/common.h" #include "libavutil/iamf.h" -#include "libavcodec/get_bits.h" #include "libavcodec/put_bits.h" #include "avformat.h" #include "avio_internal.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".
[FFmpeg-devel] [PATCH 2/3] avformat/iamf_writer, iamfenc: Avoid allocations when using dyn buffers
Use avio_get_dyn_buf()+ffio_free_dyn_buf() instead of avio_close_dyn_buf()+av_free(). This saves an allocation (and memcpy) in case all the data fits in the AVIOContext's write buffer. Signed-off-by: Andreas Rheinhardt --- libavformat/iamf_writer.c | 12 ++-- libavformat/iamfenc.c | 8 2 files changed, 10 insertions(+), 10 deletions(-) diff --git a/libavformat/iamf_writer.c b/libavformat/iamf_writer.c index f665f45b7a..5850c53c8e 100644 --- a/libavformat/iamf_writer.c +++ b/libavformat/iamf_writer.c @@ -453,11 +453,11 @@ static int iamf_write_codec_config(const IAMFContext *iamf, put_bits(&pbc, 3, 0); flush_put_bits(&pbc); -dyn_size = avio_close_dyn_buf(dyn_bc, &dyn_buf); +dyn_size = avio_get_dyn_buf(dyn_bc, &dyn_buf); avio_write(pb, header, put_bytes_count(&pbc, 1)); ffio_write_leb(pb, dyn_size); avio_write(pb, dyn_buf, dyn_size); -av_free(dyn_buf); +ffio_free_dyn_buf(&dyn_bc); return 0; } @@ -660,11 +660,11 @@ static int iamf_write_audio_element(const IAMFContext *iamf, put_bits(&pbc, 3, 0); flush_put_bits(&pbc); -dyn_size = avio_close_dyn_buf(dyn_bc, &dyn_buf); +dyn_size = avio_get_dyn_buf(dyn_bc, &dyn_buf); avio_write(pb, header, put_bytes_count(&pbc, 1)); ffio_write_leb(pb, dyn_size); avio_write(pb, dyn_buf, dyn_size); -av_free(dyn_buf); +ffio_free_dyn_buf(&dyn_bc); return 0; } @@ -796,11 +796,11 @@ static int iamf_write_mixing_presentation(const IAMFContext *iamf, put_bits(&pbc, 3, 0); flush_put_bits(&pbc); -dyn_size = avio_close_dyn_buf(dyn_bc, &dyn_buf); +dyn_size = avio_get_dyn_buf(dyn_bc, &dyn_buf); avio_write(pb, header, put_bytes_count(&pbc, 1)); ffio_write_leb(pb, dyn_size); avio_write(pb, dyn_buf, dyn_size); -av_free(dyn_buf); +ffio_free_dyn_buf(&dyn_bc); return 0; } diff --git a/libavformat/iamfenc.c b/libavformat/iamfenc.c index a02f84035a..e1003d5495 100644 --- a/libavformat/iamfenc.c +++ b/libavformat/iamfenc.c @@ -257,10 +257,10 @@ static int write_parameter_block(AVFormatContext *s, const AVIAMFParamDefinition } } -dyn_size = avio_close_dyn_buf(dyn_bc, &dyn_buf); +dyn_size = avio_get_dyn_buf(dyn_bc, &dyn_buf); ffio_write_leb(s->pb, dyn_size); avio_write(s->pb, dyn_buf, dyn_size); -av_free(dyn_buf); +ffio_free_dyn_buf(&dyn_bc); return 0; } @@ -340,10 +340,10 @@ static int iamf_write_packet(AVFormatContext *s, AVPacket *pkt) if (st->id > 17) ffio_write_leb(dyn_bc, st->id); -dyn_size = avio_close_dyn_buf(dyn_bc, &dyn_buf); +dyn_size = avio_get_dyn_buf(dyn_bc, &dyn_buf); ffio_write_leb(s->pb, dyn_size + pkt->size); avio_write(s->pb, dyn_buf, dyn_size); -av_free(dyn_buf); +ffio_free_dyn_buf(&dyn_bc); avio_write(s->pb, pkt->data, pkt->size); return 0; -- 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".
[FFmpeg-devel] [PATCH 1/3] avformat/iamf_writer: Avoid using dynamic buffer
Signed-off-by: Andreas Rheinhardt
---
libavformat/iamf_writer.c | 28 ++--
1 file changed, 6 insertions(+), 22 deletions(-)
diff --git a/libavformat/iamf_writer.c b/libavformat/iamf_writer.c
index 99602ae204..f665f45b7a 100644
--- a/libavformat/iamf_writer.c
+++ b/libavformat/iamf_writer.c
@@ -807,31 +807,15 @@ static int iamf_write_mixing_presentation(const
IAMFContext *iamf,
int ff_iamf_write_descriptors(const IAMFContext *iamf, AVIOContext *pb, void
*log_ctx)
{
-uint8_t header[MAX_IAMF_OBU_HEADER_SIZE];
-PutBitContext pbc;
-AVIOContext *dyn_bc;
-uint8_t *dyn_buf = NULL;
-int dyn_size;
-
-int ret = avio_open_dyn_buf(&dyn_bc);
-if (ret < 0)
-return ret;
+int ret;
// Sequence Header
-init_put_bits(&pbc, header, sizeof(header));
-put_bits(&pbc, 5, IAMF_OBU_IA_SEQUENCE_HEADER);
-put_bits(&pbc, 3, 0);
-flush_put_bits(&pbc);
+avio_w8(pb, IAMF_OBU_IA_SEQUENCE_HEADER << 3);
-avio_write(dyn_bc, header, put_bytes_count(&pbc, 1));
-ffio_write_leb(dyn_bc, 6);
-avio_wb32(dyn_bc, MKBETAG('i','a','m','f'));
-avio_w8(dyn_bc, iamf->nb_audio_elements > 1); // primary_profile
-avio_w8(dyn_bc, iamf->nb_audio_elements > 1); // additional_profile
-
-dyn_size = avio_close_dyn_buf(dyn_bc, &dyn_buf);
-avio_write(pb, dyn_buf, dyn_size);
-av_free(dyn_buf);
+ffio_write_leb(pb, 6);
+avio_wb32(pb, MKBETAG('i','a','m','f'));
+avio_w8(pb, iamf->nb_audio_elements > 1); // primary_profile
+avio_w8(pb, iamf->nb_audio_elements > 1); // additional_profile
for (int i = 0; i < iamf->nb_codec_configs; i++) {
ret = iamf_write_codec_config(iamf, iamf->codec_configs[i], pb);
--
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".
[FFmpeg-devel] [PATCH 2/2] avcodec/vlc: Remove unused macros
Signed-off-by: Andreas Rheinhardt
---
1. This has already been sent months ago, but I didn't apply it
because Peter Ross has sent patches that make use of them and
I did not want to force him to adapt.
2. I do not rule out that there might be scenarios in the future where
creating a static VLC (and not only VLCElem[]) would be useful,
but this zoo of macros is nevertheless too much. There should
be only two macros: One with symbols (i.e. "sparse") and one without,
both having options for flags.
libavcodec/vlc.h | 41 -
1 file changed, 41 deletions(-)
diff --git a/libavcodec/vlc.h b/libavcodec/vlc.h
index 679666801a..0cc106c499 100644
--- a/libavcodec/vlc.h
+++ b/libavcodec/vlc.h
@@ -185,47 +185,6 @@ void ff_vlc_free(VLC *vlc);
#define VLC_INIT_OUTPUT_LE 8
#define VLC_INIT_LE (VLC_INIT_INPUT_LE | VLC_INIT_OUTPUT_LE)
-#define VLC_INIT_CUSTOM_SPARSE_STATIC(vlc, bits, a, b, c, d, e, f, g, \
- h, i, j, flags, static_size) \
-do { \
-static VLCElem table[static_size]; \
-(vlc)->table = table;\
-(vlc)->table_allocated = static_size; \
-ff_vlc_init_sparse(vlc, bits, a, b, c, d, e, f, g, h, i, j,\
- flags | VLC_INIT_USE_STATIC); \
-} while (0)
-
-#define VLC_INIT_SPARSE_STATIC(vlc, bits, a, b, c, d, e, f, g, h, i, j,
static_size) \
-VLC_INIT_CUSTOM_SPARSE_STATIC(vlc, bits, a, b, c, d, e, f, g, \
- h, i, j, 0, static_size)
-
-#define VLC_INIT_LE_SPARSE_STATIC(vlc, bits, a, b, c, d, e, f, g, h, i, j,
static_size) \
-VLC_INIT_CUSTOM_SPARSE_STATIC(vlc, bits, a, b, c, d, e, f, g, \
- h, i, j, VLC_INIT_LE, static_size)
-
-#define VLC_INIT_CUSTOM_STATIC(vlc, bits, a, b, c, d, e, f, g, flags,
static_size) \
-VLC_INIT_CUSTOM_SPARSE_STATIC(vlc, bits, a, b, c, d, e, f, g, \
- NULL, 0, 0, flags, static_size)
-
-#define VLC_INIT_STATIC(vlc, bits, a, b, c, d, e, f, g, static_size) \
-VLC_INIT_SPARSE_STATIC(vlc, bits, a, b, c, d, e, f, g, NULL, 0, 0,
static_size)
-
-#define VLC_INIT_LE_STATIC(vlc, bits, a, b, c, d, e, f, g, static_size) \
-VLC_INIT_LE_SPARSE_STATIC(vlc, bits, a, b, c, d, e, f, g, NULL, 0, 0,
static_size)
-
-#define VLC_INIT_STATIC_FROM_LENGTHS(vlc, bits, nb_codes, lens, len_wrap, \
- symbols, symbols_wrap, symbols_size, \
- offset, flags, static_size) \
-do { \
-static VLCElem table[static_size]; \
-(vlc)->table = table;\
-(vlc)->table_allocated = static_size; \
-ff_vlc_init_from_lengths(vlc, bits, nb_codes, lens, len_wrap, \
- symbols, symbols_wrap, symbols_size, \
- offset, flags | VLC_INIT_USE_STATIC, \
- NULL);\
-} while (0)
-
/**
* For static VLCs, the number of bits can often be hardcoded
* at each get_vlc2() callsite. Then using a full VLC would be uneconomical,
--
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".
[FFmpeg-devel] [PATCH 1/2] avcodec/leaddec: Remove unnecessary VLC structures
One only needs the VLCElem[].
Signed-off-by: Andreas Rheinhardt
---
libavcodec/leaddec.c | 48 ++--
1 file changed, 24 insertions(+), 24 deletions(-)
diff --git a/libavcodec/leaddec.c b/libavcodec/leaddec.c
index 4e97479b03..489fe501b6 100644
--- a/libavcodec/leaddec.c
+++ b/libavcodec/leaddec.c
@@ -38,29 +38,29 @@
#define LUMA_AC_BITS 10
#define CHROMA_AC_BITS 10
-static VLC luma_dc_vlc;
-static VLC chroma_dc_vlc;
-static VLC luma_ac_vlc;
-static VLC chroma_ac_vlc;
+static VLCElem luma_dc_vlc[1 << LUMA_DC_BITS];
+static VLCElem chroma_dc_vlc[1 << CHROMA_DC_BITS];
+static VLCElem luma_ac_vlc[1160];
+static VLCElem chroma_ac_vlc[1160];
static av_cold void lead_init_static_data(void)
{
-VLC_INIT_STATIC_FROM_LENGTHS(&luma_dc_vlc, LUMA_DC_BITS,
FF_ARRAY_ELEMS(luma_dc_len),
- luma_dc_len, 1,
- 0, 0, 0,
- 0, 0, 1 << LUMA_DC_BITS);
-VLC_INIT_STATIC_FROM_LENGTHS(&chroma_dc_vlc, CHROMA_DC_BITS,
FF_ARRAY_ELEMS(chroma_dc_len),
- chroma_dc_len, 1,
- 0, 0, 0,
- 0, 0, 1 << CHROMA_DC_BITS);
-VLC_INIT_STATIC_FROM_LENGTHS(&luma_ac_vlc, LUMA_AC_BITS,
FF_ARRAY_ELEMS(luma_ac_len),
- luma_ac_len, 1,
- ff_mjpeg_val_ac_luminance, 1, 1,
- 0, 0, 1160);
-VLC_INIT_STATIC_FROM_LENGTHS(&chroma_ac_vlc, CHROMA_AC_BITS,
FF_ARRAY_ELEMS(chroma_ac_len),
- chroma_ac_len, 1,
- ff_mjpeg_val_ac_chrominance, 1, 1,
- 0, 0, 1160);
+VLC_INIT_STATIC_TABLE_FROM_LENGTHS(luma_dc_vlc, LUMA_DC_BITS,
FF_ARRAY_ELEMS(luma_dc_len),
+ luma_dc_len, 1,
+ NULL, 0, 0,
+ 0, 0);
+VLC_INIT_STATIC_TABLE_FROM_LENGTHS(chroma_dc_vlc, CHROMA_DC_BITS,
FF_ARRAY_ELEMS(chroma_dc_len),
+ chroma_dc_len, 1,
+ NULL, 0, 0,
+ 0, 0);
+VLC_INIT_STATIC_TABLE_FROM_LENGTHS(luma_ac_vlc, LUMA_AC_BITS,
FF_ARRAY_ELEMS(luma_ac_len),
+ luma_ac_len, 1,
+ ff_mjpeg_val_ac_luminance, 1, 1,
+ 0, 0);
+VLC_INIT_STATIC_TABLE_FROM_LENGTHS(chroma_ac_vlc, CHROMA_AC_BITS,
FF_ARRAY_ELEMS(chroma_ac_len),
+ chroma_ac_len, 1,
+ ff_mjpeg_val_ac_chrominance, 1, 1,
+ 0, 0);
}
typedef struct LeadContext {
@@ -199,9 +199,9 @@ static int lead_decode_frame(AVCodecContext *avctx, AVFrame
* frame,
for (int mb_x = 0; mb_x < avctx->width / 16; mb_x++)
for (int b = 0; b < (yuv20p_half ? 4 : 6); b++) {
int luma_block = yuv20p_half ? 2 : 4;
-const VLCElem * dc_vlc = b < luma_block ?
luma_dc_vlc.table : chroma_dc_vlc.table;
+const VLCElem * dc_vlc = b < luma_block ? luma_dc_vlc :
chroma_dc_vlc;
int dc_bits= b < luma_block ? LUMA_DC_BITS :
CHROMA_DC_BITS;
-const VLCElem * ac_vlc = b < luma_block ?
luma_ac_vlc.table : chroma_ac_vlc.table;
+const VLCElem * ac_vlc = b < luma_block ? luma_ac_vlc :
chroma_ac_vlc;
int ac_bits= b < luma_block ? LUMA_AC_BITS :
CHROMA_AC_BITS;
int plane = b < luma_block ? 0 : b -
(yuv20p_half ? 1 : 3);
int x, y;
@@ -231,9 +231,9 @@ static int lead_decode_frame(AVCodecContext *avctx, AVFrame
* frame,
for (int j = 0; j < avctx->height / fields / 8; j++)
for (int i = 0; i < avctx->width / 8; i++)
for (int plane = 0; plane < 3; plane++) {
-const VLCElem * dc_vlc = !plane ? luma_dc_vlc.table :
chroma_dc_vlc.table;
+const VLCElem * dc_vlc = !plane ? luma_dc_vlc :
chroma_dc_vlc;
int dc_bits= !plane ? LUMA_DC_BITS :
CHROMA_DC_BITS;
-const VLCElem * ac_vlc = !plane ? luma_ac_vlc.table :
chroma_ac_vlc.table;
+const VLCElem * ac_vlc = !plane ? luma_ac_vlc :
chroma_ac_vlc;
int ac_bits= !plane ? LUMA_AC_BITS :
CHROMA_AC_BITS;
ret = decode_block(s, &gb, dc_vlc, dc_bits, ac_vlc,
ac_bits,
--
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
ff
