Re: [FFmpeg-devel] [PATCH v2] avcodec/h264dec: Remove ff_h264_draw_horiz_band
On Fri, Jun 14, 2024 at 1:53 PM Paul B Mahol wrote: > > > > On Fri, Jun 14, 2024 at 2:41 PM Kieran Kunhya via ffmpeg-devel > wrote: >> >> On Sun, Jun 9, 2024 at 2:39 AM Andreas Rheinhardt >> wrote: >> > >> > The H.264 decoder does not support draw_horiz_band (it does not have >> > the AV_CODEC_CAP_DRAW_HORIZ_BAND), making ff_h264_draw_horiz_band() >> > legally dead. The function here always calls draw_horiz_band >> > in coded order, although the default case is display order. >> >> Why would you want a low latency decode mode with reordering? >> I have no idea about hwaccel, but I believe with low latency encoded >> video this does work. > > > Since when? > > See 0da71265d84b587c7159cd82708ca60ad050dd4c from 2003. > > flag remain commented out from then to this day. It still worked if you controlled the input. 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 v2] avcodec/h264dec: Remove ff_h264_draw_horiz_band
On Sun, Jun 9, 2024 at 2:39 AM Andreas Rheinhardt wrote: > > The H.264 decoder does not support draw_horiz_band (it does not have > the AV_CODEC_CAP_DRAW_HORIZ_BAND), making ff_h264_draw_horiz_band() > legally dead. The function here always calls draw_horiz_band > in coded order, although the default case is display order. Why would you want a low latency decode mode with reordering? I have no idea about hwaccel, but I believe with low latency encoded video this does work. 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 v3 2/2] avcodec: add external dec libvvdec for H266/VVC
In this project we prefer internal decoders to external libs. On Fri, 17 May 2024, 18:20 Cosmin Stejerean via ffmpeg-devel, < ffmpeg-devel@ffmpeg.org> wrote: > > > > On May 14, 2024, at 9:28 AM, Lynne via ffmpeg-devel < > ffmpeg-devel@ffmpeg.org> wrote: > > > > On 14/05/2024 17:09, Christian Bartnik wrote: > >> From: Thomas Siedel > >> Add external decoder VVdeC for H266/VVC decoding. > >> Register new decoder libvvdec. > >> Add libvvdec to wrap the vvdec interface. > >> Enable decoder by adding --enable-libvvdec in configure step. > >> Co-authored-by: Christian Bartnik chris1031...@gmail.com > >> Signed-off-by: Christian Bartnik > >> --- > >> configure | 5 + > >> libavcodec/Makefile| 1 + > >> libavcodec/allcodecs.c | 1 + > >> libavcodec/libvvdec.c | 617 + > >> 4 files changed, 624 insertions(+) > >> create mode 100644 libavcodec/libvvdec.c > > > > I would prefer to have this one skipped, as initially suggested. > > Why? I tried to look back through the list but didn't see anything. > > - 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] [PATCH] avcodec/h264_slice: Remove dead sps check
On Mon, 13 May 2024, 02:32 Michael Niedermayer, wrote: > On Mon, May 06, 2024 at 03:23:07AM +0200, Michael Niedermayer wrote: > > Fixes: CID1439574 Dereference after null check > > > > Sponsored-by: Sovereign Tech Fund > > Signed-off-by: Michael Niedermayer > > --- > > libavcodec/h264_slice.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > will apply > I don't understand what this fixes > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] 5 year plan & Inovation
Sent from my mobile device On Thu, 2 May 2024, 15:54 Ondřej Fiala, wrote: > On Wed May 1, 2024 at 1:01 AM CEST, Andrew Sayers wrote: > > On Tue, Apr 30, 2024 at 09:05:05PM +0200, Ondřej Fiala wrote: > > > [...] > > > > IMHO, GitHub have improved that user experience significantly in recent > years. > > Yes you're still making a fork and pushing it, but the experience is > more like > > click the edit button -> make changes (in an admittedly clunky web > editor) -> > > save and push. The rest is just kinda presented as implementation > details. > > > > That's a bit of a nitpick, but the wider point is interesting - > > GitHub etc. are fast-moving targets, so today's friction points become > > tomorrow's selling points, then the next day's lock-in opportunities. > > That makes it hard to compare to a mailing list, which is unlikely to be > > better or worse ten years from now. > That's an interesting point, and I guess it also shows how different > perspectives result in very different conclusions. To me, GitHub being > fast-moving is a negative for the same reason the whole Web tech stack > being fast-moving is. > I feel it's a huge selection bias to have arguments about Gitlab vs Mailing list handled on a mailing list. [insert meme of plane with holes in 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] [PATCH] avutil/frame: flag A53_CC side data type as allowing multiple entries
On Thu, 11 Apr 2024, 16:42 James Almer, wrote:
> Some interlaced h264 samples may export one caption per field.
>
> Signed-off-by: James Almer
> ---
> libavutil/frame.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavutil/frame.c b/libavutil/frame.c
> index 0775e2abd9..fdac6f8ee2 100644
> --- a/libavutil/frame.c
> +++ b/libavutil/frame.c
> @@ -30,7 +30,6 @@
>
> static const AVSideDataDescriptor sd_props[] = {
> [AV_FRAME_DATA_PANSCAN] = { "AVPanScan" },
> -[AV_FRAME_DATA_A53_CC] = { "ATSC A53 Part 4
> Closed Captions" },
> [AV_FRAME_DATA_MATRIXENCODING] = { "AVMatrixEncoding" },
> [AV_FRAME_DATA_DOWNMIX_INFO]= { "Metadata relevant to
> a downmix procedure" },
> [AV_FRAME_DATA_AFD] = { "Active format
> description" },
> @@ -55,6 +54,7 @@ static const AVSideDataDescriptor sd_props[] = {
> [AV_FRAME_DATA_AMBIENT_VIEWING_ENVIRONMENT] = { "Ambient viewing
> environment", AV_SIDE_DATA_PROP_GLOBAL },
> [AV_FRAME_DATA_SPHERICAL] = { "Spherical Mapping",
> AV_SIDE_DATA_PROP_GLOBAL },
> [AV_FRAME_DATA_ICC_PROFILE] = { "ICC profile",
> AV_SIDE_DATA_PROP_GLOBAL },
> +[AV_FRAME_DATA_A53_CC] = { "ATSC A53 Part 4
> Closed Captions", AV_SIDE_DATA_PROP_MULTI },
> [AV_FRAME_DATA_SEI_UNREGISTERED]= { "H.26[45] User Data
> Unregistered SEI message", AV_SIDE_DATA_PROP_MULTI },
> };
>
> --
> 2.44.0
>
But we merge the captions into a single side data element, no?
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] [EXT] Re: Query from Reuters on XZ, open source, and Microsoft
Hi Raphael, Answers in my own personal capacity, not the views of my employer, nor the views of anyone else in FFmpeg. On Wed, Apr 3, 2024 at 8:26 PM Satter, Raphael (Reuters) < raphael.sat...@thomsonreuters.com> wrote: > Dear Kieran & co., > > > > Thank you I’ve had a chance to see the talk. It’s a marker of how > invisible even critical open source projects can be that I wasn’t aware of > FFmpeg’s role in powering the likes of YouTube and Netflix. > > > > A few questions I had: > > > >- How much did Microsoft end up paying for the one-time fix? > > Microsoft did not pay for any fix. There was no actual fix, a command line option had changed between FFmpeg versions and a volunteer on our bug tracker pointed this out. A company which has several FFmpeg developers on its payroll asked Microsoft (a separate team in private) for a support contract in light of the fact FFmpeg is used in critical Microsoft products. Instead of proposing a support contract, Microsoft said a few thousand dollars was potentially available. This amount is too small to support any developer or maintenance. >- What’s the solution here? Your talk mentioned paying developers, >getting an SLA, or hiring them as consultants … but why would companies >bother when they can just free ride? I asked the same question to CISA’s >Jack Cable when he told me that companies need to “contribute back and >help build the sustainable open source ecosystem that we get so much value >from.” Sure, they “need” to do it, but who will punish them if they don’t? > > The Linux Kernel has full time developers hired by big corporations to work solely on the Linux kernel and to maintain sections of it. However, one can argue Linux is the exception in open source that proves the rule that corporations will be free riders. >- Any other thoughts you might have on this episode – or others you >think I should speak to – would be greatly appreciated. > > The Demuxed video covers the rest of my thoughts. Microsoft are not the only company with this attitude. Regards, Kieran Kunhya > >- > > Raphael > > > > *From:* Kieran Kunhya > *Sent:* Wednesday, April 3, 2024 12:39 PM > *To:* FFmpeg development discussions and patches > *Cc:* Satter, Raphael (Reuters) > *Subject:* [EXT] Re: [FFmpeg-devel] Query from Reuters on XZ, open > source, and Microsoft > > > > *External Email:* Use caution with links and attachments. > > > > Hi Raphael, > > > > I was the author of the tweet and I gave a short talk about this topic at > Demuxed at a video conference last year: > https://m.youtube.com/watch?v=OIyOEuQQsCQ=930s > <https://urldefense.com/v3/__https:/m.youtube.com/watch?v=OIyOEuQQsCQ=930s__;!!GFN0sa3rsbfR8OLyAw!fil3G3T7uUxCpJLVmYwgXrszOLckOVB2iMJMDO7QCKMoC7pWR9np5VcDBSAQwsXzhMcbBH9RL7tMr8KurldS9Ga_7Ai-q2U$> > > > > That said this is a community project and it would be best to continue the > discussion on this mailing list unless agreed otherwise. > > > > Regards, > > Kieran Kunhya > > > > On Wed, 3 Apr 2024, 16:52 Satter, Raphael (Reuters) via ffmpeg-devel, < > ffmpeg-devel@ffmpeg.org> wrote: > > Dear FFMPEG community, > > This is Raphael Satter, a journalist with Reuters. I saw your thread on X > about your experience with Microsoft in the context of the XZ story and > would love to follow up with a few questions. > > Is there a good person to talk to? I’m reachable using the details below > or on Signal/WhatsApp at +1 202 430 9389. > > Raphael > > raphael.sat...@tr.com > raphaelsatter.com > <https://urldefense.com/v3/__http:/raphaelsatter.com__;!!GFN0sa3rsbfR8OLyAw!fil3G3T7uUxCpJLVmYwgXrszOLckOVB2iMJMDO7QCKMoC7pWR9np5VcDBSAQwsXzhMcbBH9RL7tMr8KurldS9Ga_d7ggKWg$> > reuters.com/authors/raphael-satter > > Thomson Reuters > 1333 H Street NW > Washington, DC 20005 > > ☎️ +1 202 843-6302 > > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > <https://urldefense.com/v3/__https:/ffmpeg.org/mailman/listinfo/ffmpeg-devel__;!!GFN0sa3rsbfR8OLyAw!fil3G3T7uUxCpJLVmYwgXrszOLckOVB2iMJMDO7QCKMoC7pWR9np5VcDBSAQwsXzhMcbBH9RL7tMr8KurldS9Ga_oyXmFKo$> > > 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] Query from Reuters on XZ, open source, and Microsoft
Hi Raphael, I was the author of the tweet and I gave a short talk about this topic at Demuxed at a video conference last year: https://m.youtube.com/watch?v=OIyOEuQQsCQ=930s That said this is a community project and it would be best to continue the discussion on this mailing list unless agreed otherwise. Regards, Kieran Kunhya On Wed, 3 Apr 2024, 16:52 Satter, Raphael (Reuters) via ffmpeg-devel, < ffmpeg-devel@ffmpeg.org> wrote: > Dear FFMPEG community, > > This is Raphael Satter, a journalist with Reuters. I saw your thread on X > about your experience with Microsoft in the context of the XZ story and > would love to follow up with a few questions. > > Is there a good person to talk to? I’m reachable using the details below > or on Signal/WhatsApp at +1 202 430 9389. > > Raphael > > raphael.sat...@tr.com > raphaelsatter.com > reuters.com/authors/raphael-satter > > Thomson Reuters > 1333 H Street NW > Washington, DC 20005 > > ☎️ +1 202 843-6302 > > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] web/download: Extend the verification procedure to check for difference between git and release tarball
On Sat, 30 Mar 2024 at 17:30, Michael Niedermayer wrote: > On Sat, Mar 30, 2024 at 11:51:17AM -0300, James Almer wrote: > > On 3/30/2024 11:02 AM, Michael Niedermayer wrote: > > > Iam not 100% sure this is the best place to put this. But we should > somewhere > > > describe what differences are expected > > > > > > Signed-off-by: Michael Niedermayer > > > --- > > > src/download | 34 ++ > > > 1 file changed, 34 insertions(+) > > > > > > diff --git a/src/download b/src/download > > > index 0e6fa7e..34733de 100644 > > > --- a/src/download > > > +++ b/src/download > > > @@ -284,6 +284,40 @@ gpg:using RSA key > FCF986EA15E6E293A5644F10B4322F04D67658D8 > > > gpg:issuer "ffmpeg-devel@ffmpeg.org" > > > gpg: Good signature from "FFmpeg release signing key & > lt;ffmpeg-devel@ffmpeg.org" [full] > > > > > > + > > > +Verify that the release tarball matches the git tag: > (expected differences are missing .git, .gitignore and .gitattributes and > an additional VERSION file) > > > + > > > +$ diff -ru ffmpeg-5.1.4 gitdir2 > > > +Only in gitdir2/doc/doxy: .gitignore > > > +Only in gitdir2/doc/examples: .gitignore > > > +Only in gitdir2/doc: .gitignore > > > +Only in gitdir2/ffbuild: .gitignore > > > +Only in gitdir2: .git > > > +Only in gitdir2: .gitattributes > > > +Only in gitdir2: .gitignore > > > +Only in gitdir2/libavcodec: .gitignore > > > +Only in gitdir2/libavcodec/tests: .gitignore > > > +Only in gitdir2/libavdevice: .gitignore > > > +Only in gitdir2/libavdevice/tests: .gitignore > > > +Only in gitdir2/libavfilter: .gitignore > > > +Only in gitdir2/libavfilter/opencl: .gitignore > > > +Only in gitdir2/libavfilter/tests: .gitignore > > > +Only in gitdir2/libavformat: .gitignore > > > +Only in gitdir2/libavformat/tests: .gitignore > > > +Only in gitdir2/libavutil: .gitignore > > > +Only in gitdir2/libavutil/tests: .gitignore > > > +Only in gitdir2/libswresample/tests: .gitignore > > > +Only in gitdir2/libswscale/tests: .gitignore > > > +Only in gitdir2/tests/api: .gitignore > > > +Only in gitdir2/tests/checkasm: .gitignore > > > +Only in gitdir2/tests: .gitignore > > > +Only in gitdir2/tools: .gitignore > > > +Only in ffmpeg-5.1.4: VERSION > > > + > > > + > > > + > > > +Verify that the tag in git is signed > > > > The tags are signed with your key made for this purpose, > > DD1EC9E8DE085C629B3E1846B18E8928B3948D64, and not with the tarball one > > listed above. You should include it here the same way, unless the > signature > > yes but before doing that, do you think this is the best place to put all > this? > Putting this on a web host run by people we've never met before is a perfect place to put this information. Kieran ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [FFmpeg-cvslog] lavf/demux: stop calling avcodec_close()
On Wed, 27 Mar 2024 at 14:03, Michael Niedermayer wrote: > On Fri, Feb 09, 2024 at 03:19:58PM +, Anton Khirnov wrote: > > ffmpeg | branch: master | Anton Khirnov | Thu Feb > 1 08:57:24 2024 +0100| [ca18bb597223b3df5bbf8a1836d157ba58b62570] | > committer: Anton Khirnov > > > > lavf/demux: stop calling avcodec_close() > > > > Replace it with recreating the codec context. > > > > This is the last remaining blocker for deprecating avcodec_close(). > > > > > > http://git.videolan.org/gitweb.cgi/ffmpeg.git/?a=commit;h=ca18bb597223b3df5bbf8a1836d157ba58b62570 > > --- > > > > libavformat/demux.c | 61 > - > > 1 file changed, 56 insertions(+), 5 deletions(-) > > This breaks ffprobe "Closed Caption" output > before: > Stream #0:2[0x1e0]: Video: mpeg2video (Main), yuv420p(tv, progressive), > 1920x1080 [SAR 1:1 DAR 16:9], Closed Captions, 29.97 fps, 59.94 tbr, 90k tbn > Closed Captions are sparse side data, we shouldn't be exposing it like this to begin with. Kieran ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] 7.0 blocking issues
On Mon, 25 Mar 2024 at 21:10, Michael Niedermayer wrote: > On Mon, Mar 25, 2024 at 09:20:25PM +0100, Lynne wrote: > > Mar 25, 2024, 14:50 by ffm...@haasn.xyz: > > > > > On Mon, 25 Mar 2024 07:20:56 +0100 "Jean-Baptiste Kempf" < > j...@videolan.org> wrote: > > > > > >> Hello, > > >> > > >> On Mon, 25 Mar 2024, at 01:03, Michael Niedermayer wrote: > > >> > Should i wait till all issues marked as blocking 7.0 on trac are > fixed > > >> > before branching ? > > >> > > >> I think you should branch now. > > >> And get things fixed in the 7.0 branch. > > >> > > > > > > +1 > > > > > > This is a big change and some breakage is inevitable. Most bugs will > > > probably only be found once the software is released and deployed. > > > > > > When a big milestone gets bogged down by months (if not years) of > > > "blocking bugs", my understanding is that it will simply never get > > > released, and users might as well resort to using git master / nightly > > > builds at that point. > > > > > > (Any possible allusion to *other* big open source software projects is > > > purely coincidental) > > > > > > > +1, we should branch so we can unblock master from receiving > > ok, ill make the branch within the next 24h probably > > We do have several open security issues still though (some have patches on > the ML) > > I still have to check if ossfuzz is hiding any issues in unrelated tickets > (ossfuzz did that often previously and this can unveil surprises) > > Also iam behind with backporting security fixes to release branches, > (this may seem unrelated but it isnt because i always try to backport > each of my security fixes to all branches we still maintain at the same > time, > so id like to get the other branches uptodate with backports to keep > backports > in sync with a new 7.0) > Have you considered making a particular release an LTS so you don't have to backport to so many branches? 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 6/6] MAINTAINERS: Add maintainer for LC3 audio codec wrapper
> You've merged nothing yet and you want push access already? > I think this was done in good-faith saying they want to maintain. I wouldn't antagonise people for no reason. 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] avformat/flvenc: Avoid avio_write(pb, "", 0)
On Thu, 21 Mar 2024 at 13:13, Andreas Rheinhardt < andreas.rheinha...@outlook.com> wrote: > Andreas Rheinhardt: > > When the compiler chooses to inline put_amf_string(pb, ""), > > the avio_write(pb, "", 0) can be avoided. Happens with > > Clang-17 with -O1 and higher and GCC 13 with -O2 and higher > > here. > Are you able to add a comment in the code? It's not 100% clear what you are doing. Kieran ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 2/3] avfilter: add an LCEVC decoding filter
On Tue, 19 Mar 2024 at 15:27, James Almer wrote: > On 3/19/2024 12:20 PM, Kieran Kunhya wrote: > > On Tue, 19 Mar 2024 at 15:05, James Almer wrote: > > > >> On 3/19/2024 11:56 AM, Andreas Rheinhardt wrote: > >>> James Almer: > >>>> Signed-off-by: James Almer > >>>> --- > >>>>configure| 4 + > >>>>libavfilter/Makefile | 1 + > >>>>libavfilter/allfilters.c | 1 + > >>>>libavfilter/vf_lcevc.c | 466 > +++ > >>>>4 files changed, 472 insertions(+) > >>>>create mode 100644 libavfilter/vf_lcevc.c > >>>> > >>>> diff --git a/configure b/configure > >>>> index e019d1b996..4022d13f76 100755 > >>>> --- a/configure > >>>> +++ b/configure > >>>> @@ -224,6 +224,7 @@ External library support: > >>>> --enable-libcdio enable audio CD grabbing with libcdio > [no] > >>>> --enable-libcodec2 enable codec2 en/decoding using > libcodec2 > >> [no] > >>>> --enable-libdav1denable AV1 decoding via libdav1d [no] > >>>> + --enable-liblcevc_decenable AV1 decoding via liblcevc_dec [no] > >>> > >>> How is this filter supposed to decode AV1 if it does not even get > >>> AVPackets? It seems to be for decoding an EVC enhancment layer instead. > >> > >> Simple, it doesn't. It's a copy-paste fail from my part. > >> Fixed locally. > >> > >> > > From https://github.com/v-novaltd/LCEVCdec > > " This software is protected by copyrights and other intellectual > property > > rights and no license is granted to any such rights. If you would like to > > obtain a license to compile, distribute, or make any other use of this > > software, please contact V-Nova Limited i...@v-nova.com." > > > > So you want to include a library that requires ffmpeg users to obtain a > > licence to compile? > > Would adding it to the nonfree list be enough? But it's true that most > users would not be aware of the aforementioned limitations. > > This is a slippery slope to adding whatever binary blob. As the decoder is de-facto a binary blob. Kieran ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 2/3] avfilter: add an LCEVC decoding filter
On Tue, 19 Mar 2024 at 15:05, James Almer wrote: > On 3/19/2024 11:56 AM, Andreas Rheinhardt wrote: > > James Almer: > >> Signed-off-by: James Almer > >> --- > >> configure| 4 + > >> libavfilter/Makefile | 1 + > >> libavfilter/allfilters.c | 1 + > >> libavfilter/vf_lcevc.c | 466 +++ > >> 4 files changed, 472 insertions(+) > >> create mode 100644 libavfilter/vf_lcevc.c > >> > >> diff --git a/configure b/configure > >> index e019d1b996..4022d13f76 100755 > >> --- a/configure > >> +++ b/configure > >> @@ -224,6 +224,7 @@ External library support: > >> --enable-libcdio enable audio CD grabbing with libcdio [no] > >> --enable-libcodec2 enable codec2 en/decoding using libcodec2 > [no] > >> --enable-libdav1denable AV1 decoding via libdav1d [no] > >> + --enable-liblcevc_decenable AV1 decoding via liblcevc_dec [no] > > > > How is this filter supposed to decode AV1 if it does not even get > > AVPackets? It seems to be for decoding an EVC enhancment layer instead. > > Simple, it doesn't. It's a copy-paste fail from my part. > Fixed locally. > > >From https://github.com/v-novaltd/LCEVCdec " This software is protected by copyrights and other intellectual property rights and no license is granted to any such rights. If you would like to obtain a license to compile, distribute, or make any other use of this software, please contact V-Nova Limited i...@v-nova.com." So you want to include a library that requires ffmpeg users to obtain a licence to compile? 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] vvcdec: Mark as experimental
On Thu, 14 Mar 2024, 22:54 Michael Niedermayer, wrote: > On Wed, Feb 07, 2024 at 10:55:18PM +0000, Kieran Kunhya wrote: > > On Wed, 7 Feb 2024 at 22:06, Paul B Mahol wrote: > > > > > On Wed, Feb 7, 2024 at 10:13 PM Kieran Kunhya wrote: > > > > > > > $subj > > > > > > > > As discussed at FOSDEM. > > > > > > > > > > Author of this patch above is forced to FUZZ this decoder until > > > experimental flag is removed. > > > > > > > Sure, I will set some fuzzers up over the weekend. > > over a month later ... > has this been done ? > > > thx > > [...] > Frank said there was no need as he was doing it himself. I do not appreciate your passive aggressive tone. 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] avcodec/mpeg4videodec: Align idct-block appropriately
On Wed, 13 Mar 2024 at 00:53, Andreas Rheinhardt < andreas.rheinha...@outlook.com> wrote: > It is accessed via AV_RN64() in ff_simple_idct_put_int32_10bit(). > Should fix the UBSan failures in the mpeg4-simple-studio-profile > test here: > > https://fate.ffmpeg.org/report.cgi?time=20240312011016=ppc-linux-gcc-13.2-ubsan-altivec-qemu > > Signed-off-by: Andreas Rheinhardt > LGTM ___ 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] Indefinite ban request [RFC] Was: Re: [FFmpeg-trac] #10882(undetermined:new): swscale wastefully scales luma during yuv420p -> yuv422p
> > Dear LibAV core developer, thank you for this transcript. > If you feel like trolling, at least get your facts correct. 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] Indefinite ban request [RFC] Was: Re: [FFmpeg-trac] #10882(undetermined:new): swscale wastefully scales luma during yuv420p -> yuv422p
On Sun, 10 Mar 2024, 01:25 Michael Niedermayer, wrote: > Hi everyone > > Some members of the CC want to indefinitely ban Balling > from trac. And as our doc/community.texi says: > "Indefinite bans from the community must be confirmed by the General > Assembly, in a majority vote." > > Thus some CC member wishes to involve the public here > (really theres no other option, the GA cannot discuss/vote on what it > doesnt know) > > Also people have asked for more transparency and i strongly agree with > transparency. > > As reference, and to make it possible for the community to discuss > this easily without too much google searching. Ive attached the > list of all changes in trac done by Balling. > > I do not and never did support permanently banning contributors. > > In summary: since 2019 > 842 comment0' changed > 389 comment1' changed > 176 comment2' changed > 87 comment3' changed > 49 comment4' changed > 24 comment5' changed > 12 comment6' changed > 6 comment7' changed > 4 comment8' changed > 3 comment9' changed >2194 comment' changed > 10 component' changed > 12 description' changed > 29 keywords' changed > 37 owner' changed > 8 priority' changed > 7 reproduced' changed > 291 resolution' changed > 537 status' changed > 32 summary' changed > 2 type' changed > 11 version' changed > > > On Sat, Mar 02, 2024 at 10:23:32PM +0100, Michael Niedermayer wrote: > > The CC has no authority for permanent bans > > "Indefinite bans from the community must be confirmed by the General > Assembly, in a majority vote." > > > > I checked and it seems there are over 4800 events in trac from Balling, > 3783 match the word "comment" > > since 2019 > > > > By what rules does the CC deal out warnings and bans ? > > > > I think this needs to be put in writing in the docs because > > currently its pretty much arbitrary. Some people get multiple > > warnings, some people get nothing, some people are suggested to be > > just banned with no prior warning > > > On Sat, Mar 09, 2024 at 11:06:39AM +0100, Jean-Baptiste Kempf wrote: > > Hello, > > > > On Sat, 9 Mar 2024, at 08:30, Anton Khirnov wrote: > > > Quoting Michael Niedermayer (2024-03-06 13:56:39) > > >> Balling does have a quite different style in his language. Not sure > > >> what is a good term, street style, ghetto style? > > >> > > >> He used the same style of language towards me 10 days ago: > > >> https://trac.ffmpeg.org/ticket/10824#comment:18 > > > > > > This is not a "style", he understands perfectly well what he is doing. > > > > Come on, the guy is a troll. > > We're not talking about a developer from FFmpeg, but an external troll, > contributing nothing. > > Kick him out. > Do you have permission to post private CC discussion on the ML? Kieran > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 2/3] lavc: replace ff_thread_get_buffer() with ff_get_buffer()
On Fri, 8 Mar 2024 at 16:50, Nicolas George wrote: > Kieran Kunhya (12024-03-08): > > New contributors are not interested in your biased history lessons. They > > want to write code and have a modern, well run project, not a > dysfunctional > > mess. > > And we go back to the core question: does the strength of this project > come from paid-for contributors maintaining each small parts of the > project, or does it come from hackers who play with many parts of the > code and have original ideas to try? > > I think the answer is obvious. > > Unfortunately, the first category is the majority in number. Which is > why we should go back on democracy, it was a trap, and re-instate a > project leader from the second category. Or just consider that the > ousting of the leader was unlawful. > The world moved on. Open Source projects which are anarchy are few and far between (basically us). New contributors prefer stability over chaos. Kieran ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 2/3] lavc: replace ff_thread_get_buffer() with ff_get_buffer()
On Fri, 8 Mar 2024 at 16:41, Nicolas George wrote: > Kieran Kunhya (12024-03-08): > > Several recent contributors were in nappies during that piece of ancient > > history. Do you really need to bring it up incessantly and use it as your > > prism on every issue you disagree with? > > Yes, it is necessary, because the same thing is happening again. “Those > who cannot learn from history are doomed to repeat it.” New contributors > who are not familiar with these events need to ear of them all the more > New contributors are not interested in your biased history lessons. They want to write code and have a modern, well run project, not a dysfunctional mess. Kieran ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 2/3] lavc: replace ff_thread_get_buffer() with ff_get_buffer()
On Fri, 8 Mar 2024 at 15:46, Nicolas George wrote: > Sean McGovern (12024-03-08): > > It is really mean-spirited to make such comments about a project that is > no > > longer in operation. Can't we look forward instead of behind us? > > The project libav might be dead, but the people who made it are not, not > even retired, just look who signed its manifest. > > Quite the opposite, you can see they have in the recent years gained a > lot of influence in FFmpeg, and are now in the process of having FFmpeg > apply the same kind of rules and procedure and evolution ad libav. Which > is not a good idea considering the killed libav with these rules and > procedures and evolution. > Several recent contributors were in nappies during that piece of ancient history. Do you really need to bring it up incessantly and use it as your prism on every issue you disagree with? Kieran ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] FFmpeg 7.0 blocking issues
On Fri, 8 Mar 2024 at 15:04, Frank Plowman wrote: > On 08/03/2024 14:04, James Almer wrote: > > On 3/8/2024 11:02 AM, Kieran Kunhya wrote: > >> On Fri, 8 Mar 2024 at 14:00, James Almer wrote: > >> > >>> On 3/3/2024 4:35 AM, Jean-Baptiste Kempf wrote: > >>>> > >>>> n Sat, 2 Mar 2024, at 23:55, Michael Niedermayer wrote: > >>>>> On Tue, Jan 23, 2024 at 08:22:41PM +0100, Michael Niedermayer wrote: > >>>>>> Hi all > >>>>>> > >>>>>> As it was a little difficult for me to not loose track of what is > >>>>>> blocking a release. I suggest that for all release blocking issues > >>>>>> open a ticket and set Blocking to 7.0 > >>>>>> that way this: > >>>>>> https://trac.ffmpeg.org/query?blocking=~7.0 > >>>>>> > >>>>>> or for the ones not closed: > >>>>>> > >>> > https://trac.ffmpeg.org/query?status=new=open=reopened=~7.0 > >>>>>> > >>>>>> will list all blocking issues > >>>>>> > >>>>>> Ive added one, for testing that, i intend to add more if i see > >>> something > >>>>>> > >>>>>> What is blocking? (IMHO) > >>>>>> * regressions (unless its non possible to fix before release) > >>>>>> * crashes > >>>>>> * security issues > >>>>>> * data loss > >>>>>> * privacy issues > >>>>>> * anything the commuity agrees should be in the release > >>>>> > >>>>> We still have 3 blocking issues on trac > >>>>> > >>>>> do people want me to wait or ignore them and branch ? > >>>> > >>>> I think you can branch soon. > >>>> However, those 3 bugs are quite important, tbh. > >>> > >>> The bump and the AVOption changes were already applied, so IMO we can > >>> branch. > >>> The two remaining issues should not be blocking as they can be > >>> backported to 7.0 in a point release. > >>> > >> > >> VVC experimental flag is blocking. > >> > >> Kieran > > > > Is there a patch for that? > > There is this: > https://ffmpeg.org//pipermail/ffmpeg-devel/2024-February/321060.html > (missing from patchwork for some reason), but it looks like it causes > FATE to fail as is. > Yes it does not update FATE to account for experimental. Kieran ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] FFmpeg 7.0 blocking issues
On Fri, 8 Mar 2024 at 14:00, James Almer wrote: > On 3/3/2024 4:35 AM, Jean-Baptiste Kempf wrote: > > > > n Sat, 2 Mar 2024, at 23:55, Michael Niedermayer wrote: > >> On Tue, Jan 23, 2024 at 08:22:41PM +0100, Michael Niedermayer wrote: > >>> Hi all > >>> > >>> As it was a little difficult for me to not loose track of what is > >>> blocking a release. I suggest that for all release blocking issues > >>> open a ticket and set Blocking to 7.0 > >>> that way this: > >>> https://trac.ffmpeg.org/query?blocking=~7.0 > >>> > >>> or for the ones not closed: > >>> > https://trac.ffmpeg.org/query?status=new=open=reopened=~7.0 > >>> > >>> will list all blocking issues > >>> > >>> Ive added one, for testing that, i intend to add more if i see > something > >>> > >>> What is blocking? (IMHO) > >>> * regressions (unless its non possible to fix before release) > >>> * crashes > >>> * security issues > >>> * data loss > >>> * privacy issues > >>> * anything the commuity agrees should be in the release > >> > >> We still have 3 blocking issues on trac > >> > >> do people want me to wait or ignore them and branch ? > > > > I think you can branch soon. > > However, those 3 bugs are quite important, tbh. > > The bump and the AVOption changes were already applied, so IMO we can > branch. > The two remaining issues should not be blocking as they can be > backported to 7.0 in a point release. > VVC experimental flag is blocking. Kieran ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] Patch which requires a new library
On Thu, 7 Mar 2024, 20:16 Sergio Garcia Murillo, < sergio.garcia.muri...@gmail.com> wrote: > On Thu, Mar 7, 2024 at 7:02 PM Rémi Denis-Courmont > wrote: > > > Le torstaina 7. maaliskuuta 2024, 19.30.46 EET Sergio Garcia Murillo a > > écrit : > > > > The point is we don't want to use the external lib. > > > > > > For what? This is aws lib implementing the aws s3 signatures and using > > > ffmpeg crypto libs. > > > > For not depending on an external library, especially one so small and so > > specific that it is very unlikely to be shipped by the vast majority of > > FFmpeg's downstreams. > > > > That seems fair enough, however the downside is that sigv4 lib is supported > and maintained by aws and it has a proper testing suite. > As with all these "SDKs", they are supported until the vendor gets bored and/or the developers leave or get promoted. 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 which requires a new library
On Thu, 7 Mar 2024, 17:16 Sergio Garcia Murillo, < sergio.garcia.muri...@gmail.com> wrote: > El jue, 7 mar 2024, 16:30, Kieran Kunhya escribió: > > > On Thu, 7 Mar 2024 at 15:07, Sergio Garcia Murillo < > > sergio.garcia.muri...@gmail.com> wrote: > > > > > > > > Could anyone give me any pointers on what is the best way of doing > this? > > > > > > > You should use a well known crypto library to implement this in FFmpeg > (e.g > > libgcrypt, openssl > > > > In fact, the sigv library allows to pass the crypto implementation you want > to use: > > > https://github.com/aws/SigV4-for-AWS-IoT-embedded-sdk/blob/dc530f7a21ec96db62afe73e21e3b7dfad0d648c/source/include/sigv4.h#L235 > > So the patch is already using whatever crypto library ffmpeg is configured > to use. > > Anyway, not sure if i understood your feedback correctly, but my question > was about what is the best way of adding the sigv4 library as an optional > dependency in the configuration file and how to modify the patch so the > sigv4 specific code is only compiled if it is enabled by the configuration. > The point is we don't want to use the external lib. 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 which requires a new library
On Thu, 7 Mar 2024 at 15:07, Sergio Garcia Murillo < sergio.garcia.muri...@gmail.com> wrote: > > Could anyone give me any pointers on what is the best way of doing this? > You should use a well known crypto library to implement this in FFmpeg (e.g libgcrypt, openssl etc). 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".
[FFmpeg-devel] [PATCH] libavcodec/vp9dsp: Convert vp9_vert_8x8_8bpp_mmx to sse2
$subj Old: vp9_vert_8x8_8bpp_c: 8.1 vp9_vert_8x8_8bpp_mmx: 2.4 New: vp9_vert_8x8_8bpp_c: 6.8 vp9_vert_8x8_8bpp_sse2: 2.3 0001-libavcodec-vp9dsp-Convert-vp9_vert_8x8_8bpp_mmx-to-s.patch Description: Binary data ___ 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] libavcodec/h264pred: Remove pred8x8_horizontal_8_mmxext
On Sat, 2 Mar 2024 at 21:18, Andreas Rheinhardt < andreas.rheinha...@outlook.com> wrote: > Kieran Kunhya: > > $subj > > > > Old: > > pred8x8_horizontal_8_c: 6.8 > > pred8x8_horizontal_8_mmxext: 8.6 > > pred8x8_horizontal_8_ssse3: 4.8 > > > > New: > > pred8x8_horizontal_8_c: 9.2 > > pred8x8_horizontal_8_sse2: 12.2 > > pred8x8_horizontal_8_ssse3: 4.9 > > > > You do realize that the SSE2 version is worse than the mmxext version? > In fact, worse than the C version. Given that both the mmxext and sse2 > versions are worse than C, there is no point in having the mmxext one at > all and no need for an SSE2 replacement. > > - Andreas > On my machine, others may have different speeds. 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".
[FFmpeg-devel] [PATCH] libavcodec/h264pred: Remove pred8x8_horizontal_8_mmxext
$subj Old: pred8x8_horizontal_8_c: 6.8 pred8x8_horizontal_8_mmxext: 8.6 pred8x8_horizontal_8_ssse3: 4.8 New: pred8x8_horizontal_8_c: 9.2 pred8x8_horizontal_8_sse2: 12.2 pred8x8_horizontal_8_ssse3: 4.9 0001-libavcodec-h264pred-Remove-pred8x8_horizontal_8_mmxe.patch Description: Binary data ___ 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 1/2] avcodec/s302m: enable non-PCM decoding
> > i disagree > > A TC member who wants to block a patch and wants to decide if a patch > should be > blocked is in the same situation as > > a Judge who wants to sue someone and wants to judge that someone. > Whilst I am not getting into a whole philosophical legal discussion about this (to follow on from last month's Nobel Prize winning mailing list lectures on economics and business). This isn't the same thing. The TC is more like a jury where a juror can have an opinion and their opinion can be swayed by arguments during private jury discussions. The TC is doing this for the good of the project (I hope) and not to push their own agenda and it's very clear in this case there is no personal agenda. Regards, Kieran Kunhya ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] FFmpeg TC input needed
On Sat, 17 Feb 2024 at 13:16, Gyan Doshi wrote: > > Whilst s302m multiple substreams I haven't seen, Dolby E streams > internally > > contain multiple programs, often 5.1 and a 2.0 downmix. > > That is downstream of the Dolby-E decoder and user will have to use a > filter like channelsplit to bifurcate > those channels irrespective of where the s302m code resides. > The point is there are several layers of streams that also can change dynamically. > > There is a 3x3 matrix of flavours between coded Dolby E and the carriage > > PCM (16-bit, 20-bit, 24-bit). > > Have you seen a larger non-PCM word size inside a smaller AES3 word? > Actually I think that case won't work in the real world, true as the LSBs will be truncated, not passed along. Kieran ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] FFmpeg TC input needed
On Sat, 17 Feb 2024, 11:46 Gyan Doshi, wrote: > Issue: > > Patch: avcodec/s302m: enable non-PCM decoding > URL: > > https://patchwork.ffmpeg.org/project/ffmpeg/patch/20240127103854.9971-1-ffm...@gyani.pro/ > > The issue needing resolution is whether the patch should be added to the > existing s302m decoder or should that decoder > be removed and all old and new patched features inlined into the mpeg-ts > demuxer. > Additional comments: Dolby E can exist in any PCM container (wav, MP4). S302M just happens to be a tricky one. Whilst s302m multiple substreams I haven't seen, Dolby E streams internally contain multiple programs, often 5.1 and a 2.0 downmix. Strictly speaking you have to handle the case where the Dolby E frame is misaligned and spans two S302M packets which does exist (and there is ambiguity about the PTS). There is a 3x3 matrix of flavours between coded Dolby E and the carriage PCM (16-bit, 20-bit, 24-bit). 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] avcodec/jpeg2000dec: support of 2 fields in 1 AVPacket
> > I may be missing something from the previous discussion, but the > AV_FRAME_FLAG_INTERLACED should indicate when that is the case. > I am not familiar enough with j2k code to know if that flag is correctly > set or not. > > AV_FRAME_FLAG_INTERLACED signals two fields which are interleaved. What the OP wants is a single field in an AVFrame. (insert rant about why interlaced is evil blah blah). 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 1/2] avcodec/s302m: enable non-PCM decoding
On Thu, 15 Feb 2024 at 16:48, Gyan Doshi wrote: > > > On 2024-02-15 09:40 pm, Anton Khirnov wrote: > > Quoting Gyan Doshi (2024-02-15 13:31:59) > >> On 2024-02-15 04:17 pm, Anton Khirnov wrote: > >>> Hi, > >>> sorry for the delay, I've been busy fixing things for the release > >>> Quoting Gyan Doshi via ffmpeg-devel (2024-01-29 05:00:33) > On 2024-01-28 04:24 pm, Anton Khirnov wrote: > >> a) it would mean essentially inlining this decoder in the demuxer. > > Why is that a problem? This decoder seems like it shouldn't be a > > decoder. > > > > I agree with Andreas that this seems like it's a demuxer pretending > to > > be a decoder. > This module transforms the entire raw payload data to generate its > output, even if the syntax is simple which > essentially makes it a de-coder. The de-multiplexer aspect of multiple > streams is an academic possibility allowed > by the standard but not seen in any sample which makes me suspect it's > used for carriage between broadcast > facilities rather than something ever sent to an OTT provider, let > alone > an end user. > >>> If it dynamically generates nested decoders, then it's not a proper > >>> codec in our model. It should be either a part of the demuxer, or a > >>> bitstream filter (possibly inserted automatically by the demuxer). > >> s302m is a hybrid creature and does not slot cleanly into any role. So > >> there is no theoretically proper place for this component - any choice > >> is a least-out-of-place accommodation. > >> > >> But it is much more out of place inside a demuxer. Analyzing packet > >> payload and then manipulating that entire payload is much closer to a > >> decoding role than data chunk extraction for packetization. > > I don't see why specifically this property should be the one > > distinguishing demuxers from decoders, it sounds pretty arbitrary to me. > > Many demuxers apply transformations of far higher complexity to the > > bytestream before exporting it, e.g. in matroska the packet data may be > > compressed, laced, etc. > > > >> And the stream extracted from the container is meant to be SMPTE ST > >> 302 not PCM* or Dolby-E/AC-3..etc, > > "meant to be"? By whom? > > > > The point of libavformat is to abstract away the differences between > > containers as much as is reasonably feasible, and export the data in the > > format most useful to the caller for decoding or other processing. > > > >> which will both misrepresent what the container carries > > Why should the caller care? > > > >> and possibly discard S-ADM metadata, if present, in the packet. > > Why could that not be exported as side data? > > > >> A bsf in principle would work but in practice, can't as Andreas > >> clarified that bsfs can't set or alter codec_id after init. And > >> resetting the codec id requires packet inspection. > > There are two possibilities then - either extend the BSF API to support > > multiple output streams, or implement it inside libavformat as a > > post-demuxer hook called in the same place as parsing. > > > >> Nested decoders are used without issue in components like imm5 or ftr > >> (upto 64 nested decoders!) among others. There's no breaking of new > >> ground here. > > Nested decoders are certainly not "without issue" - they are a constant > > source of issues, since implementing nesting properly is very tricky. I > > am fairly sure most nested decoders we have are subtly broken in various > > ways. > > This patch facilitates a certain productive use of ffmpeg with respect > to processing of live inputs that wasn't possible earlier, > and which currently is being used successfully by multiple people over > the past few weeks. > It applies a processing model already implemented in multiple other > decoders for a number of years. I haven't seen many reports > of issues with them. And surely something being 'a constant source of > issues' would be a lot more than 'subtly broken' as you describe > them.You're the only one who has objected on architectural grounds and > this looks to be a fundamental disagreement. > If you are blocking this patch, do acknowledge here within 24 hours and > we can send this to the TC else I'll push it after that period. > Dolby E can exist in other containers apart from S302M. Raising the TC is premature. 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] avcodec/x86/simple_idct: Empty MMX state in ff_simple_idct_mmx
> Will apply this patch tomorrow unless there are objections. > LGTM ___ 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] vvcdec: Mark as experimental
On Wed, 14 Feb 2024 at 11:47, Andreas Rheinhardt <
andreas.rheinha...@outlook.com> wrote:
> Kieran Kunhya:
> > From 15c9311c49ebbe87fc4517b67cb73b3079ec3510 Mon Sep 17 00:00:00 2001
> > From: Kieran Kunhya
> > Date: Wed, 7 Feb 2024 21:10:08 +
> > Subject: [PATCH] vvcdec: Mark as experimental
> >
> > ---
> > libavcodec/vvc/vvcdec.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/libavcodec/vvc/vvcdec.c b/libavcodec/vvc/vvcdec.c
> > index 8163b5e..e0554c6 100644
> > --- a/libavcodec/vvc/vvcdec.c
> > +++ b/libavcodec/vvc/vvcdec.c
> > @@ -1011,7 +1011,7 @@ const FFCodec ff_vvc_decoder = {
> > .close = vvc_decode_free,
> > FF_CODEC_DECODE_CB(vvc_decode_frame),
> > .flush = vvc_decode_flush,
> > -.p.capabilities = AV_CODEC_CAP_DR1 | AV_CODEC_CAP_DELAY |
> AV_CODEC_CAP_OTHER_THREADS,
> > +.p.capabilities = AV_CODEC_CAP_DR1 | AV_CODEC_CAP_DELAY |
> AV_CODEC_CAP_OTHER_THREADS | AV_CODEC_CAP_EXPERIMENTAL,
> > .caps_internal = FF_CODEC_CAP_EXPORTS_CROPPING |
> FF_CODEC_CAP_INIT_CLEANUP |
> >FF_CODEC_CAP_AUTO_THREADS,
> > .p.profiles = NULL_IF_CONFIG_SMALL(ff_vvc_profiles),
>
> Did you run FATE with that? If I am not mistaken, all the VVC decoding
> tests (and probably also tests where the VVC decoder is only used to get
> stream parameters) will fail (in avcodec_open2()) now, because
> strict_std_compliance does by default not allow experimental codecs.
>
I am aware, it was more to see if there were any objections to the FOSDEM
decision to make it experimental.
Kieran
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] vvcdec: Mark as experimental
On Wed, 14 Feb 2024, 02:58 Nuo Mi, wrote: > > > > > >>> > >>> If there are no objections, I'll push it tomorrow. > > thank you, Kieran and Paul. > > > Hi Kieran, > Patchwork didn't get your patch. > I've checked the fate status locally, and it indicates that "make fate-vvc" > will fail. > Could you please send a new one to the patchwork? > > Thank you. > I am not sure how to do that on Windows unfortunately. Patchwork doesn't seem to support attachment patches. 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".
[FFmpeg-devel] [PATCH] x86/h264_pred: Convert ff_pred8x8_vertical_8_mmx to ff_pred8x8_vertical_8_sse2
$subj 0001-x86-h264_pred-Convert-ff_pred8x8_vertical_8_mmx-to-f.patch Description: Binary data ___ 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] h264_intrapred: Remove ff_pred16x16_horizontal_8_mmxext
On Sun, 11 Feb 2024 at 22:33, Andreas Rheinhardt < andreas.rheinha...@outlook.com> wrote: > James Almer: > > On 2/11/2024 6:24 PM, Kieran Kunhya wrote: > >> $subj, now with forward declaration also removed. > > > > This function is trivial to convert to SSE2, so better do that than > > removing it. Attached. > > If other functions are harder to port to SSE2, then sure, they can be > > removed. > > > > Benchmarks? > > - Andreas > For me on Haswell x64: pred16x16_horizontal_8_c: 41.5 pred16x16_horizontal_8_sse2: 32.5 pred16x16_horizontal_8_ssse3: 9.0 pred16x16_horizontal_8_c: 43.5 pred16x16_horizontal_8_mmxext: 20.7 pred16x16_horizontal_8_ssse3: 12.2 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] h264_intrapred: Remove ff_pred16x16_horizontal_8_mmxext
On Sun, 11 Feb 2024 at 21:36, James Almer wrote: > On 2/11/2024 6:24 PM, Kieran Kunhya wrote: > > $subj, now with forward declaration also removed. > > This function is trivial to convert to SSE2, so better do that than > removing it. Attached. > If other functions are harder to port to SSE2, then sure, they can be > removed.___ > > Thanks, applied. One down, couple dozen to go. 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".
[FFmpeg-devel] [PATCH] h264_intrapred: Remove ff_pred16x16_horizontal_8_mmxext
$subj, now with forward declaration also removed. 0001-h264_intrapred-Remove-ff_pred16x16_horizontal_8_mmxe.patch Description: Binary data ___ 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] h264_intrapred: Remove ff_pred16x16_horizontal_8_mmxext
$subj 0001-h264_intrapred-Remove-ff_pred16x16_horizontal_8_mmxe.patch Description: Binary data ___ 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] vp6dsp: Remove MMX code
$subj 0001-vp6dsp-Remove-MMX-code.patch Description: Binary data ___ 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] fate-suite.ffmpeg.org is very slow
Hello, I would like to know if fate-suite.ffmpeg.org is very slow to sync for anyone else? 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] vvcdec: Mark as experimental
On Thu, 8 Feb 2024 at 06:01, Nuo Mi wrote: > On Thu, Feb 8, 2024 at 6:55 AM Kieran Kunhya wrote: > > > On Wed, 7 Feb 2024 at 22:06, Paul B Mahol wrote: > > > > > On Wed, Feb 7, 2024 at 10:13 PM Kieran Kunhya wrote: > > > > > > > $subj > > > > > > > > As discussed at FOSDEM. > > > > > > > > > > Author of this patch above is forced to FUZZ this decoder until > > > experimental flag is removed. > > > > > > > Sure, I will set some fuzzers up over the weekend. > > > Better add something here > https://ffmpeg.org/developer.html#New-codecs-or-formats-checklist to > explain to people what kind of new codecs should be treated as experimental > and how they can graduate from experimental status. > Hi Nuo, Sure, this isn't saying your incredible work is bad. It's just the reality that a complex codec needs to be fuzzed heavily otherwise the security community will report FFmpeg 7.0 has a ton of security issues. Regards, Kieran Kunhya ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] vvcdec: Mark as experimental
On Wed, 7 Feb 2024 at 22:06, Paul B Mahol wrote: > On Wed, Feb 7, 2024 at 10:13 PM Kieran Kunhya wrote: > > > $subj > > > > As discussed at FOSDEM. > > > > Author of this patch above is forced to FUZZ this decoder until > experimental flag is removed. > Sure, I will set some fuzzers up over the weekend. 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".
[FFmpeg-devel] [PATCH] vvcdec: Mark as experimental
$subj As discussed at FOSDEM. Kieran 0001-vvcdec-Mark-as-experimental.patch Description: Binary data ___ 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 0/1] avformat/mpegts: fix first NAL start code splited in two different packets
On Tue, 6 Feb 2024 at 11:39, Nicolas Gaullier wrote: > >> If you think it would be better to have a related trac ticket, just > >> tell me, I can do this of course. > >> Nicolas > >> > > > >I think it's ok. I wish it were less ugly but I guess it can't be. > > > >Kieran > > Yes, of course! I am really really sorry. > Personally, I have not found a better solution as an mpegts fix, but if > anyone has a better code, of course my version can be dropped. > (I have not looked for a possible fix in the upper ffmpeg demux/parser > layers, but it would be certainly even more ugly, if possible at all). > > Again, sorry. There are some implementers who take the standards very > crude to "optimize" for every little byte unreasonably. > Fact is, here, the standard should not have allowed this! > Nicolas > Yes, I know exactly who is creating these files. 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 0/1] avformat/mpegts: fix first NAL start code splited in two different packets
On Tue, 6 Feb 2024 at 10:58, Nicolas Gaullier wrote: > >Envoyé : vendredi 2 février 2024 16:24 > >À : ffmpeg-devel@ffmpeg.org > >Objet : [PATCH 0/1] avformat/mpegts: fix first NAL start code splited in > two different packets > > > >This issue happens in the following case: > >- unaligned PES and NAL encoding > >- the first NAL of the access unit begins at the very end of a ts packet, > sometimes only the 0x00 of the trailing byte (unfortunately, this is still > conformant to the standards!) > >- the video frame is so small (ex: typically still picture) it fits in a > ts packet and a new PES is immediately started > > > >Two sample files can be found here: > >a) https://0x0.st/HDwD.ts > >b) https://0x0.st/HDwd.ts > > > >For sample a, the first NAL (AUD) is splited this way: > >0x00 / 0x00 0x00 0x01 0x09 > >And for sample b: > >0x00 0x00 0x00 / 0x01 0x09 > > > >ffmpeg -i input.ts -f null /dev/null > >=> Application provided invalid, non monotonically increasing dts... > > > > > >Nicolas Gaullier (1): > > avformat/mpegts: fix first NAL start code splited in two different > >packets > > > > libavformat/mpegts.c | 41 +++-- > > 1 file changed, 39 insertions(+), 2 deletions(-) > > Ping ? > If you think it would be better to have a related trac ticket, just tell > me, I can do this of course. > Nicolas > I think it's ok. I wish it were less ugly but I guess it can't be. 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
> Either way, iam interrested in helping with coverity work while > at the same time this environment where peole finger point and say > "is way too much" is something i dont feel comfortable to work in. > So you make an RFC but you only want comments that agree with you? > maybe doing it per hour instead of per issue is a safer way > I see the penny is finally starting to drop. 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
I have no relation and none of the above. There were some large items of piping that needed carrying and I did that to help my fellow human being through love of humankind. Kieran On Fri, 2 Feb 2024 at 14:52, Michael Niedermayer wrote: > On Wed, Jan 31, 2024 at 10:45:50PM +0000, Kieran Kunhya wrote: > > 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. > > So you, for free helped to build a FFmpeg stand for the "for profit > videolabs company" > > I am a little confused here. > What is your relation to this company ? > Where you a employee, shareholder, contractor, executive of videolabs ? > > thx > > [...] > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > "You are 36 times more likely to die in a bathtub than at the hands of a > terrorist. Also, you are 2.5 times more likely to become a president and > 2 times more likely to become an astronaut, than to die in a terrorist > attack." -- Thoughty2 > > ___ > 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, 22:40 Michael Niedermayer, wrote: > On Wed, Jan 31, 2024 at 09:54:05PM +0000, 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, 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 +0000, 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 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=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".
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
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
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
On Tue, 30 Jan 2024 at 10:46, Nicolas George wrote: > Kieran Kunhya (12024-01-30): > > So you agree the proposed Statement of Work idea in this thread isn't > going > > to fly as it won't cover actual code review? > > If that is what you read in what I wrote, I suggest you take reading > lessons intended for an early age. > Thank you for proving my point that you will be the first to block a Statement of Work. 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 Tue, 30 Jan 2024 at 10:31, Nicolas George wrote: > Kieran Kunhya (12024-01-30): > > The patches were on the mailing list for months, there was a presentation > > at VDD (livestreamed too). > > “But Mr. Dent, the plans have been available in the local planning > office for the last nine month.” — Douglas Adams > So you agree the proposed Statement of Work idea in this thread isn't going to fly as it won't cover actual code review? 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 Tue, 30 Jan 2024 at 10:12, Nicolas George wrote: > Kieran Kunhya (12024-01-29): > > A commercial SOW with a private company that took the commercial risk on > > that contract taking longer or being more difficult than anticipated or > > someone else doing the work without telling them. > > > > The terms of that contract were discussed in private and don't affect the > > project itself. > > It does not affect the project itself except in resulting in a patch > series that was developer all alone, wasting the benefit of having > several competent people contributing ideas for the core design, and an > attitude of urgency and closed-mindedness for anything that would delay > applying the series once it was posted, even if it was severe breakage > of features. > The patches were on the mailing list for months, there was a presentation at VDD (livestreamed too). Though you are proving my objections to this statement of work fallacy which is great. 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
> > I guess that conculdes the "most serious schism in the project since the > fork" > until the next most serious ? > If you think that was the sole consequence of your attempt to ram SDR into ffmpeg then I have no words. 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 Mon, 29 Jan 2024, 22:23 Cosmin Stejerean via ffmpeg-devel, < ffmpeg-devel@ffmpeg.org> wrote: > > > > On Jan 28, 2024, at 7:54 AM, Kieran Kunhya wrote: > > > > So work like Anton's threading, YUVJ removal etc, that couldn't be funded > > via bounties as they have no direct commercial value but require > expertise > > in the codebase. > > Statements of Work and milestones (by definition) are for features. > > I'm not sure those are the best examples to make that point given that > both multi-threading and YUVJ removal were funded by commercial SOWs. > > - Cosmin > A commercial SOW with a private company that took the commercial risk on that contract taking longer or being more difficult than anticipated or someone else doing the work without telling them. The terms of that contract were discussed in private and don't affect the project itself. 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 Mon, 29 Jan 2024, 18:54 Michael Niedermayer, wrote: > > > You weren't willing to compromise last time > > for your hobby, what makes you willing to compromise in that situation? > > This insult is unacceptable. > I just a few days ago stated that i intend to implement SDR within what the > community prefers or as a seperate fork. > So thats completely the opposit of what i stated > I obviously just dreamt up the most serious schism in the project since the fork. I mean there's SDR related code in git right now, you're literally gaslighting at this point. 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 Sun, 28 Jan 2024 at 21:47, Michael Niedermayer wrote: > Hi Kieran > > On Sun, Jan 28, 2024 at 08:42:00PM +0000, Kieran Kunhya wrote: > > On Sun, 28 Jan 2024, 20:37 Kieran Kunhya, wrote: > > > > > Both work fine really. For example iam not employed by FFlabs and the > work > > >> i did for them is just by sending invoices, while what i do qualifies > > >> maintenance probably close to 100%. > > >> > > > > > > Fflabs is a private company that can choose however it likes how to > > > distribute its funds. STF/SPI/FFmpeg are not the same. > > > > > > Would you like every invoice you make to be on this mailing list and > > > discussed in depth in public? And if that invoice was voted against by > the > > > GA what would you do? > > > > > > Kieran > > > > > > > Remember the outcry about SDR that literally drove people away from the > > project? Well imagine that for one of your invoices. > > Do you mean it would drive them away because of how much or how little i > work for ? > Or becuase of what i work for ? > You refused to acknowledge the public outcry over SDR for months and pushed patches the community clearly objected to (see andreas thread). That could clearly apply to invoiced work that the community disagreed with. What would you do then? You weren't willing to compromise last time for your hobby, what makes you willing to compromise in that situation? I mean it basically happened already with SDR, just without an invoice. "I think you should try to bring the work you want funded into the framework that they told us to use. Instead of complaining" And now you follow the same tactics with Derek. Accusing people of disagree with you of spreading resentment. Kieran 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".
Re: [FFmpeg-devel] Sovereign Tech Fund
> > Mysteriously, there was a total absence of similar drama there. > I wonder how it could have been possible to do that for over a decade > with not one instance of drama or problems like here. > > We had students passing the mentors review, being paid but code was > found not be clean enough yet for git master and was not yet merged > I remember no fight about any such case. > There also where the normal cases where students failed to reach the > goal and did not get paid abd code was not merged, and the ones that > succeeded got paid and code was merged. > You clearly forget the HTTP Server project. I reviewed it as 0 and was "politely" asked to change 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
> This is also why there's no need to review the invoices, and no risk of a > legitimate invoice being rejected: Because the deliverable will likely be > the commit (unless the GA objects beforehand and asks SPI to use something > else), so until it (the MR/PR) is accepted, there's no invoice to start > with. And as STF is footing the bill, there's no reason to FFmpeg concern > itself if it turned out expensive or not when reviewing, and can focus in > actually improving the program (SPI and STF will place some budget limits, > so contributors/contractors know what to expect and the money won't run > out). > Of course we need to be concerned about this, FFmpeg isn't a think tank for people's fun developments with public money from STF. The same applies to donated funds, we have a responsibility as a community to spend the money for community purposes. You're not doing SPI any favours here with these comments. Kieran On Mon, Jan 29, 2024, 12:02 Kieran Kunhya wrote: > >> >>> >> [...] the GA definitly cannot object to an invoice for a project that >>> the GA approved previously. >>> > "The General Assembly is sovereign and legitimate for all its >>> decisions regarding the FFmpeg project." >>> >>> When working with a contract (and a SOW), the General Assembly won't be >>> able to block an invoice. >>> Because the General Assembly will already have exercised its sovereignty >>> before the work started. >>> And unless the GA becomes a nation, any court of law would uphold the >>> contract. >>> >> >> In this project, acceptance of a patch is based on the technical contents >> of a patch, not a few vague paragraphs in a SoW. These decisions are made >> by the Technical Committee and the General Assembly. >> >> Tying the project contractually is unacceptable. >> >> There are plenty of "corporate" open source projects where this is fine, >> but there is a reason we are not one of those full of corporate friendly >> code like binary blobs, intrinsics, SDKs etc. >> >> 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
> > > >> [...] the GA definitly cannot object to an invoice for a project that > the GA approved previously. > > "The General Assembly is sovereign and legitimate for all its decisions > regarding the FFmpeg project." > > When working with a contract (and a SOW), the General Assembly won't be > able to block an invoice. > Because the General Assembly will already have exercised its sovereignty > before the work started. > And unless the GA becomes a nation, any court of law would uphold the > contract. > In this project, acceptance of a patch is based on the technical contents of a patch, not a few vague paragraphs in a SoW. These decisions are made by the Technical Committee and the General Assembly. Tying the project contractually is unacceptable. There are plenty of "corporate" open source projects where this is fine, but there is a reason we are not one of those full of corporate friendly code like binary blobs, intrinsics, SDKs etc. 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 1/2] avcodec/s302m: enable non-PCM decoding
On Mon, 29 Jan 2024 at 10:17, Gyan Doshi wrote:
>
>
> On 2024-01-29 02:57 pm, Nicolas Gaullier wrote:
> >> On 2024-01-28 04:24 pm, Anton Khirnov wrote:
> >>> Quoting Gyan Doshi (2024-01-26 05:23:50)
> On 2024-01-25 06:47 pm, Andreas Rheinhardt wrote:
> > Gyan Doshi:
> >>> On 2024-01-25 10:29 am, Andreas Rheinhardt wrote:
> >>> Gyan Doshi:
> Set up framework for non-PCM decoding in-place and add support
> for Dolby-E decoding.
>
> Useful for direct transcoding of non-PCM audio in live inputs.
> ---
> configure | 1 +
> doc/decoders.texi | 40 +++
> libavcodec/s302m.c | 609
> +
> 3 files changed, 543 insertions(+), 107 deletions(-)
>
> diff --git a/configure b/configure index c8ae0a061d..8db3fa3f4b
> 100755
> --- a/configure
> +++ b/configure
> @@ -2979,6 +2979,7 @@ rv20_decoder_select="h263_decoder"
> rv20_encoder_select="h263_encoder"
> rv30_decoder_select="golomb h264pred h264qpel mpegvideodec
> rv34dsp"
> rv40_decoder_select="golomb h264pred h264qpel mpegvideodec
> rv34dsp"
> +s302m_decoder_select="dolby_e_decoder"
> screenpresso_decoder_deps="zlib"
> shorten_decoder_select="bswapdsp"
> sipr_decoder_select="lsp"
> diff --git a/doc/decoders.texi b/doc/decoders.texi index
> 293c82c2ba..9f85c876bf 100644
> --- a/doc/decoders.texi
> +++ b/doc/decoders.texi
> @@ -347,6 +347,46 @@ configuration. You need to explicitly
> configure the build with
> An FFmpeg native decoder for Opus exists, so users can
> decode Opus
> without this library.
> +@section s302m
> +
> +SMPTE ST 302 decoder.
> +
> +SMPTE ST 302 is a method for storing AES3 data format within an
> +MPEG
> Transport
> +Stream. AES3 streams can contain LPCM streams of 2, 4, 6 or 8
> channels with a
> +bit depth of 16, 20 or 24-bits at a sample rate of 48 kHz.
> +They can also contain non-PCM codec streams such as AC-3 or
> Dolby-E.
> +
> >>> This sounds like we should add bitstream filters to extract the
> >>> proper underlying streams instead.
> >>> (I see only two problems with this approach: The BSF API needs to
> >>> set the CodecID of the output during init, but at this point no
> >>> packet has reached the BSF to determine it. And changing codec IDs
> >>> mid-stream is also not supported.)
> >> In theory, this decoder shouldn't exist, as it is just a carrier,
> >> whether of LPCM or non-PCM.
> >> FFmpeg architecture also imposes a fundamental limitation in that
> >> one s302m stream may carry multiple payload streams and we support
> >> only one decoding context per input stream
> > Then why does the demuxer not separate the data into multiple
> streams?
> I didn't add demuxing support for this codec in MPEGTS, but I can
> venture
>
> a) it would mean essentially inlining this decoder in the demuxer.
> >>> Why is that a problem? This decoder seems like it shouldn't be a
> >>> decoder.
> >>>
> >>> I agree with Andreas that this seems like it's a demuxer pretending to
> >>> be a decoder.
> >> This module transforms the entire raw payload data to generate its
> output, even if the syntax is simple which essentially makes it a de-coder.
> The de-multiplexer aspect of multiple streams is an academic possibility
> allowed by the >standard but not seen in any sample which makes me suspect
> it's used for carriage between broadcast facilities rather than something
> ever sent to an OTT provider, let alone an end user.
> >>
> >> Regards,
> >> Gyan
> > AFAIK, DolbyE may be found on satellite feeds, for carriage between
> broadcast facilities, and thus it makes them accessible so they may be
> grabbed by "end users". Otherwise, it is "broadcast professional end
> users", which are users too. AFAIK, its most common form is 20Bits and you
> simply "cannot" have a single stream in a 20Bit carrier; but indeed, most
> of the time only the first stream ("program") is used and the second is a
> downmix; but not always. For example, you can have a first program which is
> standard 5.1 and a second program with Audio Description.
> In the samples I have, including yours, the outermost layer is AES3
> which contains one inner stream Dolby-E, which in turn contains 8
> channels constituting multiple programs. Those are programs downstream
> of the dolby_e decoder. That's not what we are talking about. The
> discussion here is about multiple payload streams within the AES3 layer
> - streams stored in subframe mode e.g. a Dolby-E and AC-3 or LPCM in
> alternate subframes/frames. I've no such
Re: [FFmpeg-devel] Sovereign Tech Fund
> I would cry ;) > > seriously, I have said very clearly in my first mail that there can be NO > late > objections to a STF/SPI Project. objections must be before its submitted to > STF. So theres no way the GA could object to an invoice, the GA could > object to > the project before its started only > > I do remember this concern from you and the FFlabs CEO. > thats why i made sure that this case would not be possible. So no the GA > definitly cannot object to an invoice for a project that the GA approved > previously. That said I do not belive the GA (which is made of adult > intelligent > humans) would block an invoice for a project that was previously approved. > "The General Assembly is sovereign and legitimate for all its decisions regarding the FFmpeg project." 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 Sun, 28 Jan 2024 at 21:19, Jonatas L. Nogueira wrote: > While it's true a traditional SOW breaks work into milestones, we're going > for a simplified one here out of need. Think on when you ask for > consulting, not when you ask for a feature. You should not assume we want > to write eg. "Finish removing YUVJ by date X" ─ that's not the plan and as > you said it makes no sense (even less when you consider the SOW are > individual agreements, and we're likely going to have multiple people > working on it). > You misunderstand this community. There are disagreements going on for decades. Unless it's a black and white delivery of a feature, this will never fly in FFmpeg. 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 1/2] avcodec/s302m: enable non-PCM decoding
> > Why is that a problem? This decoder seems like it shouldn't be a > decoder. > > I agree with Andreas that this seems like it's a demuxer pretending to > be a decoder. > The framing is in the PCM layer itself, you have the same issue repeated in every container that accepts PCM (and Dolby E does exist in those). FFmpeg only allows one layer of demux so it has to go somewhere. This is a second layer of demux. 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 Sun, 28 Jan 2024, 20:37 Kieran Kunhya, wrote: > Both work fine really. For example iam not employed by FFlabs and the work >> i did for them is just by sending invoices, while what i do qualifies >> maintenance probably close to 100%. >> > > Fflabs is a private company that can choose however it likes how to > distribute its funds. STF/SPI/FFmpeg are not the same. > > Would you like every invoice you make to be on this mailing list and > discussed in depth in public? And if that invoice was voted against by the > GA what would you do? > > Kieran > Remember the outcry about SDR that literally drove people away from the project? Well imagine that for one of your invoices. 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
> > Both work fine really. For example iam not employed by FFlabs and the work > i did for them is just by sending invoices, while what i do qualifies > maintenance probably close to 100%. > Fflabs is a private company that can choose however it likes how to distribute its funds. STF/SPI/FFmpeg are not the same. Would you like every invoice you make to be on this mailing list and discussed in depth in public? And if that invoice was voted against by the GA what would you do? 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
> > infrastructure etc which all lends itself to salaried work. > > employment & salary is one way to pay someone. Sending invoices and doing > some paperwork before is the other. > > Both work fine really. For example iam not employed by FFlabs and the work > i did for them is just by sending invoices, while what i do qualifies as > maintenance probably close to 100%. > As Remi says this is not true, bounties are suitable more for discrete features and employment more for maintenance. 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
> > Also it has to be said, that the example is hypothetical, you are not > going to > do that work. You seem more interrested in arguing against anything > related to SPI > This is a completely false accusation. I have no issues with SPI as an organisation. The hardware I bought and host was reimbursed promptly and efficiently by SPI. I find the attacks (to coin your favourite word) unacceptable. 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 Sun, 28 Jan 2024 at 19:20, Jonatas L. Nogueira wrote: > That's not a problem at all; because you can divide the work into discrete > pieces after it's done (on the invoice), just like liberal professionals > (eg. accountants, lawyers, administrators, etc.) > As an open source project we can't give developers de-facto unbounded time to work on something. It's not the same as accountants and lawyers. They know roughly how long a set of accounts or a legal operation will take from experience. These changes are one-off. Many of the maintenance projects in FFmpeg can't be easily split up into the simple examples you provide. FFmpeg is hugely coupled, one change in code like YUVJ affects a lot of unrelated things. It's not at all easy to cost this work. The threading changes took the best part of a year and are still ongoing. This does not lend itself well to SoW/bounties. 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
> > > Statements of Work and milestones (by definition) are for features. > > The SoW suggestion/need came from a lawyer that jonatas asked IIUC. > so i can just suggest to put work like what you list above into a SOW like > framework. Or maybe Jonatas can clarify, in case i misunderstood > My point is that ongoing maintenance can't be split into discrete pieces of work, nor arguably can a given timescale be associated with cleanup. For example YUVJ is difficult, until you remove it and see the bugs you don't know how long it will take. This is not suited to the bounty/SoW methodology. We don't need STF to be funding features, we need maintenance, infrastructure etc which all lends itself to salaried work. 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 Sun, 28 Jan 2024 at 03:26, Michael Niedermayer wrote: > Hi all > > We are offered to apply for a sponsorship of FFmpeg by the Sovereign Tech > Fund (STF). > > Please read the following to get a better understanding what STF is about: > (In short it is about maintenance and sustainability, not features) > https://www.sovereigntechfund.de/programs/applications > > As some probably already know, Thilo has worked with STF to work out > many details of this. SPI will handle the financials for FFmpeg. > Everyone willing to benefit from this sponsorship must not be a US > sanctioned > entity or in a US sanctioned country. And must sign a contractor agreement > and simplified SoW with SPI. > "A SOW purpose is to protect the contracted from doing a > work and not getting paid, and to protect the contractor from paying for a > work which wasn't wanted" > > At this point, what we need is a list of Projects so we can submit an > application to STF > at or before 12th Feb. (at the 14th they have a meeting and will review > our submission) > What STF told us, they need ATM is: > > - A scope of work for the project to defined before hand for the upcoming > review and eventually a contract. It doesn’t have to be tied to specific > people. > - The contract STF will sign with SPI will be a service agreement based on > that SOW and milestones. Payment of invoices will be contingent and after > delivery (aka performance) of agreed upon milestones. > > My suggestion is that we create a Trac WIKI page similar to the ideas > page for GSoC. " To receive funding from the Sovereign Tech Fund, technologies must be under-supplied or threatened by other circumstances, acute or long-term, such as market consolidation or severe dependencies. The lack of support and resources or technical alternatives places the technologies in a vulnerable state that threatens the existence and sustainability of the project." I read that as STF is there to support maintenance of open source projects, not just another GSoC wishlist. So work like Anton's threading, YUVJ removal etc, that couldn't be funded via bounties as they have no direct commercial value but require expertise in the codebase. Statements of Work and milestones (by definition) are for features. Regards, Kieran Kunhya ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] FFmpeg 7.0 blocking issues
> > What is blocking? (IMHO) > * regressions (unless its non possible to fix before release) > * crashes > * security issues > Is VVC being run through oss-fuzz yet? I think it would be a shame for 7.0 to be released then a ton of CVEs come out and the security community hysterically saying FFmpeg is insecure. 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 1/2] avcodec/s302m: enable non-PCM decoding
On Tue, 23 Jan 2024 at 14:51, Devin Heitmueller < devin.heitmuel...@ltnglobal.com> wrote: > On Tue, Jan 23, 2024 at 4:05 AM Kieran Kunhya wrote: > > Yes, and the other uncertainty is that the PTS must be cotimed with the > > video so you have to guess whether it's the previous PTS or the next one. > > Isn't the correct behavior to determine the offset within the raw PCM > payload, and use that to determine the actual PTS of the embedded > non-PCM packet? Unless I"m misreading the code, it seems like it's > simply setting the PTS of the non-pcm packet to be the PTS of the > original S302 packet, which will result in incorrect A/V sync. > Quite the opposite, Dolby E by design is cotimed with the video frame and S302M PTS is also cotimed with the video frame. The ambiguity is when Dolby E is misaligned, is it misaligned to the next video frame, or the previous one. For AC-3 yes, the offset matters but that's a different story. 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 1/2] avcodec/s302m: enable non-PCM decoding
On Tue, 23 Jan 2024 at 08:33, Gyan Doshi wrote: > > > On 2024-01-23 01:26 pm, Kieran Kunhya wrote: > > On Tue, 23 Jan 2024 at 06:50, Gyan Doshi wrote: > > > >> Set up framework for non-PCM decoding in-place and > >> add support for Dolby-E decoding. > >> > >> Useful for direct transcoding of non-PCM audio in live inputs. > >> > > Does this handle a Dolby E packet spanning multiple S302M packets? I'm > not > > saying you should support this as it's rare and very annoying to > implement > > but it does happen. > > No, this does not handle spanned payload. > I have access to a sample where it looks like the packetizer got > mis-aligned and I think > cases like those are better handled by a parser. > > Adding support for multiple payload packets in one 302m packet is on my > to-do although > the parser is better suited for that as well as the last payload packet > might be fragmented. > > Regards, > Gyan > Yes, and the other uncertainty is that the PTS must be cotimed with the video so you have to guess whether it's the previous PTS or the next one. 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 1/2] avcodec/s302m: enable non-PCM decoding
On Tue, 23 Jan 2024 at 06:50, Gyan Doshi wrote: > Set up framework for non-PCM decoding in-place and > add support for Dolby-E decoding. > > Useful for direct transcoding of non-PCM audio in live inputs. > Does this handle a Dolby E packet spanning multiple S302M packets? I'm not saying you should support this as it's rare and very annoying to implement but it does happen. 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] Hardware purchase request: AVX512-capable laptop
On Thu, 18 Jan 2024 at 09:55, Paul B Mahol wrote: > On Thu, Jan 18, 2024 at 10:53 AM Kieran Kunhya wrote: > > > > >> It's a high-spec 4-core machine with 16Gb of RAM, and still very > > > >> usable these days, but it'll take around 400 dollars to repair, > > > >> as a new original screen is expensive (290), battery isn't cheap > (60), > > > >> and parts are in general in demand as it's out of support by now. > > > >> > > > > > > > > well i would certainly support ffmpeg-SPI paying for these parts > > > > if it helps you. > > > > > > > > > > Right, thanks. But would the main two currently objecting agree? > > > I don't think they monitor this thread anymore, but their objections > > stand. > > > > > > > I object to buying parts that may not work, or the install may not go > well > > (I tried repairing my old XPS and it was not simple and I broke the > > screen). > > I don't think "worth a try" is fair to FFmpeg donors. > > > > Just kill the project and take all the money already. > How would buying parts even work, hardware is the property of SPI. How can SPI own half a laptop? For reference all the hardware I host for FFmpeg reimbursed by SPI has a "property of FFmpeg project" sticker on it. Regards, Kieran Kunhya ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] Hardware purchase request: AVX512-capable laptop
> >> It's a high-spec 4-core machine with 16Gb of RAM, and still very > >> usable these days, but it'll take around 400 dollars to repair, > >> as a new original screen is expensive (290), battery isn't cheap (60), > >> and parts are in general in demand as it's out of support by now. > >> > > > > well i would certainly support ffmpeg-SPI paying for these parts > > if it helps you. > > > > Right, thanks. But would the main two currently objecting agree? > I don't think they monitor this thread anymore, but their objections stand. > I object to buying parts that may not work, or the install may not go well (I tried repairing my old XPS and it was not simple and I broke the screen). I don't think "worth a try" is fair to FFmpeg donors. 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] Hardware purchase request: AVX512-capable laptop
On Tue, 16 Jan 2024, 11:50 Paul B Mahol, wrote: > On Tue, Jan 16, 2024 at 11:06 AM Kieran Kunhya wrote: > > > > > > > A ticket doesn't have durability. > > > > > > > A Ryzen 5 vs Ryzen 7 in the same laptop chassis doesn't change its > > durability, it only doubles the laptop's price. > > > > Are you CEO of FFmpeg or FFlabs now? > I'm CEO of librempeg and librempeglabs. 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] Hardware purchase request: AVX512-capable laptop
> > A ticket doesn't have durability. > A Ryzen 5 vs Ryzen 7 in the same laptop chassis doesn't change its durability, it only doubles the laptop's price. 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] Hardware purchase request: AVX512-capable laptop
> > If you think it's reasonable, you shouldn't block it. > If you have conditions, you should concisely state them. > If you think this is entirely unreasonable and falls outside of the scope > of > the project's donation funds, then I would expect you to apply the > same pragmatic standards when it comes to future refund requests, > be it personal choices such as parking and travel expenses. > Your laptop choice is one of the most expensive in the market and likely much more expensive than the laptop the majority of developers use. Buy an 11th Gen Intel NUC and a cheap laptop and access it remotely. By your own analogy you want SPI to pay for your First Class ticket from London to New York when there are cheaper alternatives. 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] Hardware purchase request: AVX512-capable laptop
On Sun, 14 Jan 2024, 17:24 Lynne, wrote: > Jan 9, 2024, 19:57 by d...@lynne.ee: > > > Jan 3, 2024, 04:30 by d...@lynne.ee: > > > >> Jan 3, 2024, 04:04 by d...@lynne.ee: > >> > >>> Jan 3, 2024, 02:22 by jamr...@gmail.com: > >>> > On 1/2/2024 9:56 PM, Lynne wrote: > > > As some of you know, my laptop died nearly 2 years ago, and > > I've been working on a desktop machine, which is currently a Zen 3. > > AVX512 has become more popular in the meantime, with Zen 4 > > and future AMD CPUs shipping with it, but currently, we have very > > little AVX512. > > In short, I'd like a machine which runs an AVX512-capable > > AMD CPU, and as the world is opening up more and more, I'd > > like for it to be portable. > > > > I've looked around a lot, but as Intel still has a firm monopoly, > > the options are limited (7940H(S), 7945HX, 7845HX, 8945HS). > > What I think I've settled for is an ASUS Vivobook Pro 15, with a > > 7940HS CPU (the second least powerful Zen 4 mobile CPU), > > > > 7940HS is the highest Ryzen 9 model from the 7040 series. Not sure > where you got second least powerful from. > > > https://en.wikipedia.org/wiki/List_of_AMD_Ryzen_processors#Phoenix_(7040_series,_Zen_4/RDNA3_based) > > >>> > >>> Was reading Wikipedia, and thought it was a Zen 3, my mistake > >>> (and AMD's mistake for making 4 versioning formats): > >>> https://en.wikipedia.org/wiki/List_of_AMD_Ryzen_processors > >>> > >>> > > currently trading for 1999.0 EUR on amazon.de. > > > > > https://www.amazon.de/-/en/Vivobook-Display-R9-7940HS-Windows-Keyboard/dp/B0BRYTS8MR > > > > The other alternative I've found is a Lenovo Legion 7 Pro, but > > it's more expensive at 2399 EUR (currently seems temporarily > > discounted due to the holidays). > > > > I see a Lenovo Yoga Pro 7 available for 1099 EUR. > https://www.amazon.de/-/en/Lenovo-Display-Graphics-Blue-Green-Premium/dp/B0CGLPVQHK/ > > Same amount of RAM, screen resolution and storage, and a Ryzen 7. > > >>> > >>> It's a good suggestion, but I have a better one, that's somewhat more > expensive, > >>> but has a better screen, better build quality, and is cheaper than the > Vivobook: > >>> > >>> A Lenovo ThinkPad P14s Gen 4 with the following options: > >>> - Windows 14 Home (if you don't pick Windows, the OLED display is not > available for no reason) > >>> - 32Gb of RAM > >>> - 1Tb "performance" SSD (it's 70 EUR more, but twice the size) > >>> - 2880x1800 OLED monitor > >>> - 4-cell battery (only 10 EUR more) > >>> - English (EU) keyboard, without backlighting > >>> > >>> > https://www.lenovo.com/de/de/configurator/cto/index.html?bundleId=21K9CTO1WWDE2 > >>> > >> > >> Correction: link I pasted was for the P16s, not the P14s, this is the > correct link: > >> > https://www.lenovo.com/de/de/configurator/cto/index.html?bundleId=21K5CTO1WWDE2 > >> > > > > Ping. So far I have one approval from Michael. > > > > Ping. > I agree with Remi's objections to this. 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] fate: add VVC decoder tests
On Sat, 6 Jan 2024 at 05:10, Martin Storsjö wrote: > On Sat, 6 Jan 2024, Kieran Kunhya wrote: > > > On Sat, 6 Jan 2024 at 02:35, Nuo Mi wrote: > > > >> On Sat, Jan 6, 2024 at 9:13 AM James Almer wrote: > >> > >> > On 1/5/2024 10:09 PM, Nuo Mi wrote: > >> > > On Sat, Jan 6, 2024 at 5:09 AM James Almer > wrote: > >> > > > >> > > Here are the clips and their sources: > >> > > https://github.com/ffvvc/tests/tree/main > >> > > passed v1 is about 194M , and each clip may have different features. > >> It's > >> > > better to add them all to vvc-conformance, without name change > >> > > passed v2 is about 871M , we can pick some smaller clips that cover > all > >> > bit > >> > > depths and color formats. > >> > > >> > Yeah, it's not so much about the size of the samples than it is about > >> > runtime. That many tests would make a fate run take way too much, even > >> > after we add assembly. > >> > We need to choose a subset that cover as many decoding cases as > possible. > >> > > >> Good point. > >> If I disable the asm code on my machine, "make fate-hevc" takes about 1 > >> minute and 26 seconds. We can use this as the baseline. > >> If we remove the largest 5 files in v1, we can decode it in 5 minutes > and > >> 13 seconds. We can remove more if we find it's still slow. > >> From a feature perspective, TREE_A_HHI_3.bit may cover major features in > >> TREE_B_HHI_3.bit, TREE_C_HHI_3.bit. It's reasonable to remove them > >> > >> Largest 5 files: > >> TRANS_B_Chipsnmedia_2.bit > >> TRANS_A_Chipsnmedia_2.bit > >> TREE_B_HHI_3.bit > >> LFNST_D_HHI_3.bit > >> TREE_C_HHI_3.bit > >> > > > > Could we have an option in the FATE config file to do a full run and > allow > > admins to turn it on at will? > > I appreciate there are a lot of embedded devices where running all the > VVC > > decodes will take forever. But at the same time there are powerful > devices > > like M1, NUC etc where this isn't a big deal and I'd like to see VVC > tested > > in full. > > We already have an option that is somewhat like this; > --disable-large-tests, which is documented as "disable tests that use a > large amount of memory", primarily intended for small SBCs and similar - > where running fate takes a long time in any case, but one doesn't want it > to fail due to some few tests doing 8k resolutions and such. > > Not sure if that's the right match here, or if we should add another > option, like --enable-extra-tests, which would be opt-in? > > // Martin > No opinion either way. 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] Hardware purchase request: AVX512-capable laptop
On Sat, 6 Jan 2024, 20:55 Lynne, wrote: > Jan 7, 2024, 01:40 by kier...@obe.tv: > > > On Sat, 6 Jan 2024, 19:00 Lynne, wrote: > > > >> Jan 7, 2024, 00:36 by kier...@obe.tv: > >> > >> > On Sat, 6 Jan 2024, 16:06 Lynne, wrote: > >> > > >> >> Jan 6, 2024, 21:15 by r...@remlab.net: > >> >> > >> >> > > >> >> > > >> >> > Le 6 janvier 2024 20:26:42 GMT+02:00, Michael Niedermayer < > >> >> mich...@niedermayer.cc> a écrit : > >> >> > > >> >> >> > >> >> >> > >> >> > >I think some kind of remotely usable system does make sense for > every > >> >> volunteer > >> >> > >who wants to work. It simply results in more available time for > that > >> >> work. > >> >> > > >> >> >> > >> >> >> > >> >> > >Even i (who doesnt travel volunteerly around) have needed and > used my > >> >> notebook > >> >> > >for FFmpeg away from my desktop system many times. > >> >> > >When ive spend some time in appartments of other familiy members, > >> when > >> >> i had to > >> >> > >change my own apartment due to very noisy neighbors and so forth > >> >> > > >> >> >> > >> >> >> > >> >> > >Maybe a compromise would be a cheap laptop that is just used to > login > >> >> and > >> >> > >access the more powerfull hardware via SSH ? > >> >> > > >> >> > That sounds much more sensible indeed. > >> >> > > >> >> > >> >> To address your concerns about limited lifetime and durability, > >> >> I chose the ThinkPad. It's not a +2k eur Macbook, it's serviceable, > >> >> and I can still do stuff with it that I can't do on my current > setups. > >> >> We have many times more than enough to cover it, and make no > >> >> impact on the project's finances. > >> >> I could agree to jamrial's suggestion too, though I don't think it > >> >> would be as durable or problem-free. > >> >> > >> > > >> > But didn't you say the ThinkPad doesn't support AVX-512? > >> > > >> > >> Err, no? It has a 7840U, which according to > >> https://www.amd.com/en/product/13186 > >> has support for AVX512. > >> I was initially confused as it's labelled as a Ryzen 7, and I thought > >> Ryzen 9s > >> were the ones based on Zen 4, but afaik both 7 and 9 are Zen 4. > >> > > > > There is still no reason why you couldn't use the dedicated NUC that has > > AVX512 and access it remotely with a much cheaper laptop. > > > > It's more practical to work on a local machine without having to > compile everything, and setting up for accurate benchmarking is > doable as you wouldn't disturb anyone else's work by switching > the scheduler or fixing the frequency. > I also messaged you about getting access to the Ampere machine > a little over a week ago, but you didn't respond, so sysadmin latency > is high. > The nuc has everything setup correctly for this. Regarding access to the ampere, there is a further discussion to be had off-list. 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] Hardware purchase request: AVX512-capable laptop
On Sat, 6 Jan 2024, 19:00 Lynne, wrote: > Jan 7, 2024, 00:36 by kier...@obe.tv: > > > On Sat, 6 Jan 2024, 16:06 Lynne, wrote: > > > >> Jan 6, 2024, 21:15 by r...@remlab.net: > >> > >> > > >> > > >> > Le 6 janvier 2024 20:26:42 GMT+02:00, Michael Niedermayer < > >> mich...@niedermayer.cc> a écrit : > >> > > >> >> > >> >> > >> > >I think some kind of remotely usable system does make sense for every > >> volunteer > >> > >who wants to work. It simply results in more available time for that > >> work. > >> > > >> >> > >> >> > >> > >Even i (who doesnt travel volunteerly around) have needed and used my > >> notebook > >> > >for FFmpeg away from my desktop system many times. > >> > >When ive spend some time in appartments of other familiy members, > when > >> i had to > >> > >change my own apartment due to very noisy neighbors and so forth > >> > > >> >> > >> >> > >> > >Maybe a compromise would be a cheap laptop that is just used to login > >> and > >> > >access the more powerfull hardware via SSH ? > >> > > >> > That sounds much more sensible indeed. > >> > > >> > >> To address your concerns about limited lifetime and durability, > >> I chose the ThinkPad. It's not a +2k eur Macbook, it's serviceable, > >> and I can still do stuff with it that I can't do on my current setups. > >> We have many times more than enough to cover it, and make no > >> impact on the project's finances. > >> I could agree to jamrial's suggestion too, though I don't think it > >> would be as durable or problem-free. > >> > > > > But didn't you say the ThinkPad doesn't support AVX-512? > > > > Err, no? It has a 7840U, which according to > https://www.amd.com/en/product/13186 > has support for AVX512. > I was initially confused as it's labelled as a Ryzen 7, and I thought > Ryzen 9s > were the ones based on Zen 4, but afaik both 7 and 9 are Zen 4. > There is still no reason why you couldn't use the dedicated NUC that has AVX512 and access it remotely with a much cheaper laptop. 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] Hardware purchase request: AVX512-capable laptop
On Sat, 6 Jan 2024, 16:06 Lynne, wrote: > Jan 6, 2024, 21:15 by r...@remlab.net: > > > > > > > Le 6 janvier 2024 20:26:42 GMT+02:00, Michael Niedermayer < > mich...@niedermayer.cc> a écrit : > > > >> > >> > > >I think some kind of remotely usable system does make sense for every > volunteer > > >who wants to work. It simply results in more available time for that > work. > > > >> > >> > > >Even i (who doesnt travel volunteerly around) have needed and used my > notebook > > >for FFmpeg away from my desktop system many times. > > >When ive spend some time in appartments of other familiy members, when > i had to > > >change my own apartment due to very noisy neighbors and so forth > > > >> > >> > > >Maybe a compromise would be a cheap laptop that is just used to login > and > > >access the more powerfull hardware via SSH ? > > > > That sounds much more sensible indeed. > > > > To address your concerns about limited lifetime and durability, > I chose the ThinkPad. It's not a +2k eur Macbook, it's serviceable, > and I can still do stuff with it that I can't do on my current setups. > We have many times more than enough to cover it, and make no > impact on the project's finances. > I could agree to jamrial's suggestion too, though I don't think it > would be as durable or problem-free. > But didn't you say the ThinkPad doesn't support AVX-512? 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] fate: add VVC decoder tests
On Sat, 6 Jan 2024 at 02:35, Nuo Mi wrote: > On Sat, Jan 6, 2024 at 9:13 AM James Almer wrote: > > > On 1/5/2024 10:09 PM, Nuo Mi wrote: > > > On Sat, Jan 6, 2024 at 5:09 AM James Almer wrote: > > > > > >> On 1/3/2024 9:19 PM, James Almer wrote: > > >>> Signed-off-by: James Almer > > >>> --- > > >>>tests/Makefile| 1 + > > >>>tests/fate/vvc.mak| 50 +++ > > >>>tests/ref/fate/vvc-conformance-APSALF_A_2 | 13 ++ > > >>>tests/ref/fate/vvc-conformance-APSLMCS_D_1| 37 + > > >>>tests/ref/fate/vvc-conformance-APSMULT_A_4| 53 +++ > > >>>tests/ref/fate/vvc-conformance-AUD_A_3| 35 + > > >>>tests/ref/fate/vvc-conformance-BUMP_A_2 | 45 ++ > > >>>tests/ref/fate/vvc-conformance-CROP_B_4 | 105 ++ > > >>>.../fate/vvc-conformance-CodingToolsSets_A_2 | 7 + > > >>>tests/ref/fate/vvc-conformance-DCI_A_3| 7 + > > >>>tests/ref/fate/vvc-conformance-HRD_A_3| 65 + > > >>>tests/ref/fate/vvc-conformance-OPI_B_3| 6 + > > >>>tests/ref/fate/vvc-conformance-PHSH_B_1 | 11 ++ > > >>>tests/ref/fate/vvc-conformance-POC_A_1| 25 > > >>>tests/ref/fate/vvc-conformance-PPS_B_1| 69 + > > >>>tests/ref/fate/vvc-conformance-RAP_A_1| 6 + > > >>>tests/ref/fate/vvc-conformance-SAO_A_3| 65 + > > >>>tests/ref/fate/vvc-conformance-SCALING_A_1| 69 + > > >>>tests/ref/fate/vvc-conformance-SLICES_A_3 | 30 > > >>>tests/ref/fate/vvc-conformance-SPS_B_1| 133 > > ++ > > >>>tests/ref/fate/vvc-conformance-STILL_B_1 | 10 ++ > > >>>tests/ref/fate/vvc-conformance-SUBPIC_A_3 | 9 ++ > > >>>tests/ref/fate/vvc-conformance-TILE_A_2 | 14 ++ > > >>>tests/ref/fate/vvc-conformance-VPS_A_3| 6 + > > >>>tests/ref/fate/vvc-conformance-WPP_A_3| 54 +++ > > >>>tests/ref/fate/vvc-conformance-WP_A_3 | 22 +++ > > >>>tests/ref/fate/vvc-conformance-WRAP_A_4 | 14 ++ > > >>>27 files changed, 961 insertions(+) > > >>>create mode 100644 tests/fate/vvc.mak > > >>>create mode 100644 tests/ref/fate/vvc-conformance-APSALF_A_2 > > >>>create mode 100644 tests/ref/fate/vvc-conformance-APSLMCS_D_1 > > >>>create mode 100644 tests/ref/fate/vvc-conformance-APSMULT_A_4 > > >>>create mode 100644 tests/ref/fate/vvc-conformance-AUD_A_3 > > >>>create mode 100644 tests/ref/fate/vvc-conformance-BUMP_A_2 > > >>>create mode 100644 tests/ref/fate/vvc-conformance-CROP_B_4 > > >>>create mode 100644 > > tests/ref/fate/vvc-conformance-CodingToolsSets_A_2 > > >>>create mode 100644 tests/ref/fate/vvc-conformance-DCI_A_3 > > >>>create mode 100644 tests/ref/fate/vvc-conformance-HRD_A_3 > > >>>create mode 100644 tests/ref/fate/vvc-conformance-OPI_B_3 > > >>>create mode 100644 tests/ref/fate/vvc-conformance-PHSH_B_1 > > >>>create mode 100644 tests/ref/fate/vvc-conformance-POC_A_1 > > >>>create mode 100644 tests/ref/fate/vvc-conformance-PPS_B_1 > > >>>create mode 100644 tests/ref/fate/vvc-conformance-RAP_A_1 > > >>>create mode 100644 tests/ref/fate/vvc-conformance-SAO_A_3 > > >>>create mode 100644 tests/ref/fate/vvc-conformance-SCALING_A_1 > > >>>create mode 100644 tests/ref/fate/vvc-conformance-SLICES_A_3 > > >>>create mode 100644 tests/ref/fate/vvc-conformance-SPS_B_1 > > >>>create mode 100644 tests/ref/fate/vvc-conformance-STILL_B_1 > > >>>create mode 100644 tests/ref/fate/vvc-conformance-SUBPIC_A_3 > > >>>create mode 100644 tests/ref/fate/vvc-conformance-TILE_A_2 > > >>>create mode 100644 tests/ref/fate/vvc-conformance-VPS_A_3 > > >>>create mode 100644 tests/ref/fate/vvc-conformance-WPP_A_3 > > >>>create mode 100644 tests/ref/fate/vvc-conformance-WP_A_3 > > >>>create mode 100644 tests/ref/fate/vvc-conformance-WRAP_A_4 > > >> > > >> This is using the samples already in the fate suite. I don't know if > > >> they give good coverage (I think i chose them to cover as much CBS > > >> methods as possible, not caring about actual decode paths, and not > even > > >> that is complete), so I'd like someone more familiar with the > > >> conformance suite to suggest better samples to upload and use, too. > > >> > > > > > > Here are the clips and their sources: > > > https://github.com/ffvvc/tests/tree/main > > > passed v1 is about 194M , and each clip may have different features. > It's > > > better to add them all to vvc-conformance, without name change > > > passed v2 is about 871M , we can pick some smaller clips that cover all > > bit > > > depths and color formats. > > > > Yeah, it's not so much about the size of the samples than it is about > > runtime. That many tests would make a fate run take way too much, even > > after we add assembly. > > We need to choose a subset that
Re: [FFmpeg-devel] Hardware purchase request: AVX512-capable laptop
On Fri, 5 Jan 2024, 17:25 Rémi Denis-Courmont, wrote: > Le keskiviikkona 3. tammikuuta 2024, 2.56.12 EET Lynne a écrit : > > As some of you know, my laptop died nearly 2 years ago, and > > I've been working on a desktop machine, which is currently a Zen 3. > > AVX512 has become more popular in the meantime, with Zen 4 > > and future AMD CPUs shipping with it, but currently, we have very > > little AVX512. > > Frankly, generally speaking, I don't think it makes sense to buy laptops > for > development *unless* desktop systems are not an option. > > And here, a desktop system is not only an option, but it is the > technically > better and already purchased option. A desktop is cheaper, more faster, > more > serviceable and more incrementally upgradeable. More prosaically a desktop > system is much more suitable to occupational well-being - laptops are > awfully > inadequate in terms of ergonomy, unless they are docked, at which point > they > become expensive under-provisioned desktops. > > A laptop would of course be necessary whilst spending extended periods of > your > time away from home. But if so, that would be a discretionary choice of > life > style choice. There is nothing wrong with doing that per se, but I really > don't think that an open-source foundation should be addressing > discretionary > life style choices. > Furthermore there is already an AVX-512 development machine I host for FFmpeg that several developers use. 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/2] web: add a news entry for VVC
On Fri, 5 Jan 2024 at 10:50, Anton Khirnov wrote: > --- > src/index | 8 > 1 file changed, 8 insertions(+) > > diff --git a/src/index b/src/index > index a2536ff..98cc516 100644 > --- a/src/index > +++ b/src/index > @@ -35,6 +35,14 @@ > News > > > + January 3rd, 2024, native VVC decoder > + > + The libavcodec library now contains a native VVC > (Versatile Video Coding) > + decoder, supporting a large subset of the codec's features. Further > optimizations and > + support for more features are coming soon. The code was written by Nuo > Mi, Xu Mu, > + Frank Plowman, Shaun Loo, and Wu Jianhua. > + > + >December 18th, 2023, IAMF support > >The libavformat library can now read and write https://aomediacodec.github.io/iamf/;>IAMF > -- > 2.42.0 > LGTM ___ 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 0/1] fftools/ffprobe: dump contents of the AV_FRAME_DATA_SEI_UNREGISTERED
On Wed, 3 Jan 2024 at 15:44, Stefano Sabatini wrote: > On date Tuesday 2024-01-02 22:08:54 +0000, Kieran Kunhya wrote: > [...] > > The OP wants to test an implementation they have and they should do it > > using the API, not using ffprobe to test their third party implementation > > of something. > > > > > > "Parsed by FFmpeg" sounds like you are proposing to extend the FFmpeg > > > API to parse some more information (about the SEI subtype?) and make > > > it available through some more specific SEI side data? > > > > > > > As the OP says, this SEI data is from "MISB ST 0604" which is something > > that could be implemented in FFmpeg and parsed properly like all the > other > > side data instead of just writing random binary data to the terminal. > > Fine, so you are proposing to extend the parser to put this > information in the side data. This makes sense to me and sounds a > better approach than the original proposal. > SEIs are reordered so they need to go through the decoder to be frame accurate. I don't believe the parser is enough. 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] Hardware purchase request: AVX512-capable laptop
Sent from my mobile device On Wed, 3 Jan 2024, 03:30 Lynne, wrote: > Jan 3, 2024, 04:04 by d...@lynne.ee: > > > Jan 3, 2024, 02:22 by jamr...@gmail.com: > > > >> On 1/2/2024 9:56 PM, Lynne wrote: > >> > >>> As some of you know, my laptop died nearly 2 years ago, and > >>> I've been working on a desktop machine, which is currently a Zen 3. > >>> AVX512 has become more popular in the meantime, with Zen 4 > >>> and future AMD CPUs shipping with it, but currently, we have very > >>> little AVX512. > >>> In short, I'd like a machine which runs an AVX512-capable > >>> AMD CPU, and as the world is opening up more and more, I'd > >>> like for it to be portable. > >>> > >>> I've looked around a lot, but as Intel still has a firm monopoly, > >>> the options are limited (7940H(S), 7945HX, 7845HX, 8945HS). > >>> What I think I've settled for is an ASUS Vivobook Pro 15, with a > >>> 7940HS CPU (the second least powerful Zen 4 mobile CPU), > >>> > >> > >> 7940HS is the highest Ryzen 9 model from the 7040 series. Not sure > where you got second least powerful from. > >> > >> > https://en.wikipedia.org/wiki/List_of_AMD_Ryzen_processors#Phoenix_(7040_series,_Zen_4/RDNA3_based) > >> > > > > Was reading Wikipedia, and thought it was a Zen 3, my mistake > > (and AMD's mistake for making 4 versioning formats): > > https://en.wikipedia.org/wiki/List_of_AMD_Ryzen_processors > > > > > >>> currently trading for 1999.0 EUR on amazon.de. > >>> > >>> > https://www.amazon.de/-/en/Vivobook-Display-R9-7940HS-Windows-Keyboard/dp/B0BRYTS8MR > >>> > >>> The other alternative I've found is a Lenovo Legion 7 Pro, but > >>> it's more expensive at 2399 EUR (currently seems temporarily > >>> discounted due to the holidays). > >>> > >> > >> I see a Lenovo Yoga Pro 7 available for 1099 EUR. > https://www.amazon.de/-/en/Lenovo-Display-Graphics-Blue-Green-Premium/dp/B0CGLPVQHK/ > >> > >> Same amount of RAM, screen resolution and storage, and a Ryzen 7. > >> > > > > It's a good suggestion, but I have a better one, that's somewhat more > expensive, > > but has a better screen, better build quality, and is cheaper than the > Vivobook: > > > > A Lenovo ThinkPad P14s Gen 4 with the following options: > > - Windows 14 Home (if you don't pick Windows, the OLED display is not > available for no reason) > > - 32Gb of RAM > > - 1Tb "performance" SSD (it's 70 EUR more, but twice the size) > > - 2880x1800 OLED monitor > > - 4-cell battery (only 10 EUR more) > > - English (EU) keyboard, without backlighting > > > > > https://www.lenovo.com/de/de/configurator/cto/index.html?bundleId=21K9CTO1WWDE2 > > > > Correction: link I pasted was for the P16s, not the P14s, this is the > correct link: > > https://www.lenovo.com/de/de/configurator/cto/index.html?bundleId=21K5CTO1WWDE2 Why not just buy an Intel NUC 11th gen with AVX512? There are also Zen 4 NUC clones. 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 0/1] fftools/ffprobe: dump contents of the AV_FRAME_DATA_SEI_UNREGISTERED
> > My point is that we might opt-out the verbose dump if we have a clear > criterion for opting-in/out. For example -show_data is off by default, > and we could mark special side-data fields with some flags to opt them > out by default. Again, for unregistered SEI you don't have a choice. Some encoders put tons of private data in there. Some of the stuff is human readable, some of it isn't. > > Again, this is something that should either be parsed by FFmpeg or done > via > > the API. > > I still don't understand. The CLI exposes what the API does, so if the > API can't do it, the CLI cannot do either. The OP wants to test an implementation they have and they should do it using the API, not using ffprobe to test their third party implementation of something. "Parsed by FFmpeg" sounds like you are proposing to extend the FFmpeg > API to parse some more information (about the SEI subtype?) and make > it available through some more specific SEI side data? > As the OP says, this SEI data is from "MISB ST 0604" which is something that could be implemented in FFmpeg and parsed properly like all the other side data instead of just writing random binary data to the terminal. I don't understand why any of this is hard to comprehend. 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".
