[FFmpeg-devel] root access voting
Hi At teh current videolan developer days there where several surprise votes on FFmpegs infractructure. And to the best of my knowledge no remote participation and no recording. So let me try to reply to the idea of the general assembly choosing who has root access. We have seen a raise of increasingly sophisticated attacks in recent times. For example thx xz backdoor, where the maintainer was pressured by many people to add jia tan as maintainer who then eventually added a sophisticated hidden backdoor. Compromising xz and ssh. (Which almost was not even detected) We have seen batteries being exchanged by explosives by the mosad injuring members of a terrorist organization and probably a few innocent people. You may agree with fighting terror but do you agree with explosives, in maybe the phone someone of your familiy bought on ebay ? Just yesterday, lottie-player was replaced by a compromised version. Stealing peoples money. Our GA is build of everyone who has "authored more than 20 patches in the last 36 months in the main FFmpeg repository" This is a very low bar for an attacker. Even if we did KYC (which i think we should not) hiring 50 people to each write 20 patches is very doable even for a small company or heck even a single individual could do this. Let alone, a state actor. What this means, and i think this is obvious to everyone, is the GA cannot control critical infractructure access or things that allow attacks by state actors. Thats besides the root admins should generally be professional admins and not "popular politicans". Which is ultimately what a popular vote produces. Also the root team has to get along with each other and trust each other, obviously. And last, where is that professional admin who wants to do work and who has no root access ? I have to the best of my knowledge given every professional admin we have on the FFmpeg team, who needed root access, root access. Yes i would not give root access to people who are involved in every 2nd flamewar or who i totally do not get along. Or if the request comes in a strange context, ... But does the GA want to override that ? You think that would improve things ? Please lets not turn root access into a harris vs trump style democracy If theres a professional, trusted, admin and there work that needs to be done and (s)he has time, ability and will to do that work, nothing strange, and noone says they dont get along with him/her. I have and will give them root access. if thats not the case I dont think people would want me to give them root access. thx -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Complexity theory is the science of finding the exact solution to an approximation. Benchmarking OTOH is finding an approximation of the exact signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] root access voting
On 11/2/2024 4:34 AM, Michael Niedermayer wrote: Hi At teh current videolan developer days there where several surprise votes on FFmpegs infractructure. And to the best of my knowledge no remote participation and no recording. So let me try to reply to the idea of the general assembly choosing who has root access. We have seen a raise of increasingly sophisticated attacks in recent times. For example thx xz backdoor, where the maintainer was pressured by many people to add jia tan as maintainer who then eventually added a sophisticated hidden backdoor. Compromising xz and ssh. (Which almost was not even detected) We have seen batteries being exchanged by explosives by the mosad injuring members of a terrorist organization and probably a few innocent people. You may agree with fighting terror but do you agree with explosives, in maybe the phone someone of your familiy bought on ebay ? Just yesterday, lottie-player was replaced by a compromised version. Stealing peoples money. Our GA is build of everyone who has "authored more than 20 patches in the last 36 months in the main FFmpeg repository" This is a very low bar for an attacker. Even if we did KYC (which i think we should not) hiring 50 people to each write 20 patches is very doable even for a small company or heck even a single individual could do this. Let alone, a state actor. What this means, and i think this is obvious to everyone, is the GA cannot control critical infractructure access or things that allow attacks by state actors. Thats besides the root admins should generally be professional admins and not "popular politicans". Which is ultimately what a popular vote produces. Also the root team has to get along with each other and trust each other, obviously. And last, where is that professional admin who wants to do work and who has no root access ? I have to the best of my knowledge given every professional admin we have on the FFmpeg team, who needed root access, root access. Yes i would not give root access to people who are involved in every 2nd flamewar or who i totally do not get along. Or if the request comes in a strange context, ... But does the GA want to override that ? You think that would improve things ? Please lets not turn root access into a harris vs trump style democracy If theres a professional, trusted, admin and there work that needs to be done and (s)he has time, ability and will to do that work, nothing strange, and noone says they dont get along with him/her. I have and will give them root access. if thats not the case I dont think people would want me to give them root access. thx ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". maybe train an A.I. that monitors and analyze each new patch can be useful ___ ffmpeg-devel mailing list ffmpeg-devel@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] INSTALL: explain the circular dependency issue and solution
Signed-off-by: Michael Niedermayer --- INSTALL.md | 8 1 file changed, 8 insertions(+) diff --git a/INSTALL.md b/INSTALL.md index 3b220bc6ff2..4398ca12fa1 100644 --- a/INSTALL.md +++ b/INSTALL.md @@ -15,3 +15,11 @@ NOTICE -- - Non system dependencies (e.g. libx264, libvpx) are disabled by default. + +NOTICE for Package Maintainers +-- + + - It is recommanded to build FFmpeg twice, first with minimal external depandancies so + that 3rd party packages, which depend on FFmpegs libavutil/libavfilter/libavcodec/libavformat + can then be build. And last build FFmpeg with full depandancies (which may in turn depen on + some of these 3rd party packages). This avoids circular depandancies during build. -- 2.47.0 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] INSTALL: explain the circular dependency issue and solution
On 11/2/2024 2:24 PM, Michael Niedermayer wrote: Signed-off-by: Michael Niedermayer --- INSTALL.md | 8 1 file changed, 8 insertions(+) diff --git a/INSTALL.md b/INSTALL.md index 3b220bc6ff2..4398ca12fa1 100644 --- a/INSTALL.md +++ b/INSTALL.md @@ -15,3 +15,11 @@ NOTICE -- - Non system dependencies (e.g. libx264, libvpx) are disabled by default. + +NOTICE for Package Maintainers +-- + + - It is recommanded to build FFmpeg twice, first with minimal external depandancies so Recommended, dependencies (this one repeated below). + that 3rd party packages, which depend on FFmpegs libavutil/libavfilter/libavcodec/libavformat + can then be build. And last build FFmpeg with full depandancies (which may in turn depen on "be built", depend. + some of these 3rd party packages). This avoids circular depandancies during build. LGTM otherwise. OpenPGP_signature.asc Description: OpenPGP digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v6] avcodec/jpeg2000: Fix FF_DWT97_INT to pass the conformance testing defined in ISO/IEC 15444-4
The patch LTGM with the following nits:
- the commit message width
- an extra empty line in decode_refpass()
Both can be fixed at merge time.
A larger question, which is probably best left to later or never, is
whether we care that the compression ratio has been changed for a
given value of the (arbitrary) Q value.
There is now a recommendation for defining a Q value for JPEG 2000
[1], so maybe we ought to focus on this.
[1]
https://ds.jpeg.org/documents/jpeg2000/wg1n100430-098-COM-Guideline_on_controlling_JPEG_2000_image_quality_using_a_single_parameter.pdf
On Fri, Nov 1, 2024 at 11:26 PM Osamu Watanabe
wrote:
>
> Fix for the integer version of the inverse 9-7 DWT processing (FF_DWT97_INT,
> https://trac.ffmpeg.org/ticket/10123), which is activated with -flags
> +bitexact.
>
> I went through the code path for the DWT 9-7 transform (integer) and improved
> precision to match conformance codestream.
>
> As a result, the encoded codestream size is slightly larger for a given Q
> value. For example, -flags +bitexact -i lena.pnm -q: 20 -format j2k -y
> tmp.j2c gives 13K (HEAD) and 19K (with this patch).
>
> This commit also updates the source and reference files for affected FATE
> tests.
>
> Signed-off-by: Osamu Watanabe
> ---
> libavcodec/jpeg2000.c| 11 +-
> libavcodec/jpeg2000dec.c | 150 +--
> libavcodec/jpeg2000dwt.c | 47 +++
> libavcodec/jpeg2000dwt.h | 1 +
> libavcodec/jpeg2000htdec.c | 9 +-
> libavcodec/tests/jpeg2000dwt.c | 5 +
> tests/ref/fate/j2k-dwt | 40 +++---
> tests/ref/fate/jpeg2000-dcinema | 4 +-
> tests/ref/fate/jpeg2000dec-p0_04 | 2 +-
> tests/ref/fate/jpeg2000dec-p0_05 | 2 +-
> tests/ref/fate/jpeg2000dec-p0_09 | 2 +-
> tests/ref/vsynth/vsynth1-jpeg2000-97 | 8 +-
> tests/ref/vsynth/vsynth2-jpeg2000-97 | 8 +-
> tests/ref/vsynth/vsynth3-jpeg2000-97 | 8 +-
> tests/ref/vsynth/vsynth_lena-jpeg2000-97 | 8 +-
> 15 files changed, 163 insertions(+), 142 deletions(-)
>
> diff --git a/libavcodec/jpeg2000.c b/libavcodec/jpeg2000.c
> index d6ffb02319..7911500901 100644
> --- a/libavcodec/jpeg2000.c
> +++ b/libavcodec/jpeg2000.c
> @@ -260,9 +260,7 @@ static void init_band_stepsize(AVCodecContext *avctx,
> band->f_stepsize *= F_LFTG_X * F_LFTG_X * 4;
> break;
> }
> -if (codsty->transform == FF_DWT97) {
> -band->f_stepsize *= pow(F_LFTG_K, 2*(codsty->nreslevels2decode -
> reslevelno) + lband - 2);
> -}
> +band->f_stepsize *= pow(F_LFTG_K, 2*(codsty->nreslevels2decode -
> reslevelno) + lband - 2);
> }
>
> if (band->f_stepsize > (INT_MAX >> 15)) {
> @@ -270,12 +268,7 @@ static void init_band_stepsize(AVCodecContext *avctx,
> av_log(avctx, AV_LOG_ERROR, "stepsize out of range\n");
> }
>
> -band->i_stepsize = band->f_stepsize * (1 << 15);
> -
> -/* FIXME: In OpenJPEG code stepsize = stepsize * 0.5. Why?
> - * If not set output of entropic decoder is not correct. */
> -if (!av_codec_is_encoder(avctx->codec))
> -band->f_stepsize *= 0.5;
> +band->i_stepsize = (int)floorf(band->f_stepsize * (1 << 15));
> }
>
> static int init_prec(AVCodecContext *avctx,
> diff --git a/libavcodec/jpeg2000dec.c b/libavcodec/jpeg2000dec.c
> index 5b05ff2455..c9d8b025b1 100644
> --- a/libavcodec/jpeg2000dec.c
> +++ b/libavcodec/jpeg2000dec.c
> @@ -1885,14 +1885,15 @@ static void decode_sigpass(Jpeg2000T1Context *t1, int
> width, int height,
> && !(t1->flags[(y+1) * t1->stride + x+1] & (JPEG2000_T1_SIG
> | JPEG2000_T1_VIS))) {
> if (ff_mqc_decode(&t1->mqc, t1->mqc.cx_states +
> ff_jpeg2000_getsigctxno(t1->flags[(y+1) * t1->stride + x+1] & flags_mask,
> bandno))) {
> int xorbit, ctxno =
> ff_jpeg2000_getsgnctxno(t1->flags[(y+1) * t1->stride + x+1] & flags_mask,
> &xorbit);
> -if (t1->mqc.raw)
> - t1->data[(y) * t1->stride + x] =
> ff_mqc_decode(&t1->mqc, t1->mqc.cx_states + ctxno) ? -mask : mask;
> -else
> - t1->data[(y) * t1->stride + x] =
> (ff_mqc_decode(&t1->mqc, t1->mqc.cx_states + ctxno) ^ xorbit) ?
> - -mask : mask;
> -
> +if (t1->mqc.raw) {
> +t1->data[(y) * t1->stride + x] |=
> ff_mqc_decode(&t1->mqc, t1->mqc.cx_states + ctxno) << 31;
> +t1->data[(y) * t1->stride + x] |= mask;
> +} else {
> +t1->data[(y) * t1->stride + x] |=
> (ff_mqc_decode(&t1->mqc, t1->mqc.cx_states + ctxno) ^ xorbit) << 31;
> +t1->data[(y) * t1->stride + x] |= mask;
> +}
>
[FFmpeg-devel] Develop FFmpeg through your browser?
Hi Should we move to a different development system ? I dont know, but I belive we should carefully consider if we want to move to a gitlab like system that is a commercal / corporate and not community driven system that we can get stuck in. Companies get sold change owner/leader, and in no time gitlab can be owned by microsoft or another corporation and be merged with github or similar for example. Also i have a dislike for these browser based systems. Should we move to videolan? This is a seperate question and has nothing to do with changing the "development system" ? We can install gitlab on our infrastructure, if the community decides that it wants gitlab. We can also install anything else the community wants. If people do move to videolan, i will not come along. I see not the slightest reason to give up our independance. Again, gitlab, is something i would avoid, but we can set it up on our infrastructure, ill come along i probably will no longer be able to test every patch. Because i just wont deal with this gitlab thing for each patch. Its a loss for the community and for code quality probably. OTOH, If some people move to videolan, I will not join them. That said, I find the discussions about such key decissions being done each year on "videolan developer days", inappropriate and hostile. Such a conference is great for people to sozialize, meet, discuss technical things drink their favorit drinks together and eat their favorit foods together. but key project decissions should be discussed where everyone has equal access. (and not just the option of traveling around the world) Not only does this matter for fairness and finding the best solutions, there is also the danger of political parties forming from the clustering of people discussing mainly within their silos. PS: As you certainly realize, iam trying to comment here on a discussion that i was not part of, and that i also only know a very terse summary of, so this certainly doesnt exactly match in. But what else can i do when people dont talk in public about the FFmpeg free software project and instead meet in private for that. (if its not private, provide a link to a recording of the whole uncut discussion) thx -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB "I am not trying to be anyone's saviour, I'm trying to think about the future and not be sad" - Elon Musk signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 00/19] fate: fix several dependencies
On Sun, Oct 27, 2024 at 02:09:16AM +0200, Nicolas Gaullier wrote: > It is impossible to double check every single test case. > With my default basic setup, fate-list is unchanged, which is a good start... > Nothing extraordinary, but here is a limited setup I used: > https://pastebin.com/GZ72Qz7r > And a simple script to test multiple derived setups: > https://pastebin.com/neziaJqu > Note: for this script to work, my previous patch > "avcodec/ac3dec: fix build when eac3 decoder is disabled" > must be applied first. > > I don't intend to fix everything. The idea is to make things like > "configure --disable-everything --enable-decoder=foo" > pass. > > Note: I don't know how I should split the patches. > I decided to gather some of them together to limit the number of patches, > but maybe I should split strictly one/mak file, let me know. > > Nicolas Gaullier (19): > tests/Makefile: make easier to check for multiple dependencies > fate/all: add missing dependencies for extradata bsf > fate/demux: fix multiple dependencies > fate/audio: fix ffprobe dependency instead of ffmpeg > fate/all: switch-fix mov muxer dependency to mp4 muxer dependency > fate/mov: fix multiple dependencies > fate/gapless: fix multiple dependencies > fate/lavf-container: fix multiple dependencies > fate/vorbis: fix multiple dependencies > fate/aac: fix multiple dependencies > fate/ac3: fix multiple dependencies > fate/audio: fix multiple dependencies > fate/cover-art: fix multiple dependencies > fate/mpeg4: fix multiple dependencies > fate/pcm: fix multiple dependencies > fate/hevc: fix multiple dependencies > fate/all: fix multiple dependencies > fate/all: add missing file protocol dependencies > fate/all: add missing crc/framecrc/md5/framemd5/pipe dependencies i havnt had time to really review or test but wanted to say thanks for these ive seem dependency issues and not had the time to look deeper thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Concerning the gods, I have no means of knowing whether they exist or not or of what sort they may be, because of the obscurity of the subject, and the brevity of human life -- Protagoras signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 11/15] avformat/flacdec:Return correct error-codes on read-failure
On Wed, Oct 30, 2024 at 11:44:37AM +0100, Tomas Härdin wrote:
> tis 2024-10-29 klockan 18:42 +0100 skrev Michael Niedermayer:
> > On Tue, Oct 29, 2024 at 03:50:05PM +0100, Tomas Härdin wrote:
> > > Reasonable enough. Might want a sample
> > >
> > > Spotify comments
> > >
> > > Unexpected EOF is treated as invalid data
> > >
> > > /Tomas
> >
> > > flacdec.c | 20
> > > 1 file changed, 16 insertions(+), 4 deletions(-)
> > > 8cf62c7b8b7e576cc0e2a0a1e49c4f42be5fc254 0011-avformat-flacdec-
> > > Return-correct-error-codes-on-read-.patch
> > > From 4d803c5f5c13e194a0e52d287f021b73ec7172bd Mon Sep 17 00:00:00
> > > 2001
> > > From: Ulrik
> > > Date: Thu, 26 Jan 2023 17:51:02 +0100
> > > Subject: [PATCH 11/15] avformat/flacdec:Return correct error-codes
> > > on
> > > read-failure
> > >
> > > Forward errors from `avio_read` directly. When `avio_read` sees EOF
> > > before
> > > expected bytes can be read, consistently return
> > > `AVERROR_INVALIDDATA`
> > >
> > > We used to return `AVERROR(AVERROR_INVALIDDATA)` when failing to
> > > read
> > > metadata block headers. `AVERROR_INVALIDDATA` is already negative,
> > > so
> > > wrapping in `AVERROR` leads to double-negation.
> > >
> > > We used to return `AVERROR(EIO)` when failing to read extended
> > > metadata.
> > > However, many times, the IO-layer is not at fault, the input data
> > > is simply
> > > corrupted (truncated), so we return `AVERROR_INVALIDDATA` here as
> > > well.
> > > ---
> > > libavformat/flacdec.c | 20
> > > 1 file changed, 16 insertions(+), 4 deletions(-)
> > >
> > > diff --git a/libavformat/flacdec.c b/libavformat/flacdec.c
> > > index 9f65c25864..be305fec82 100644
> > > --- a/libavformat/flacdec.c
> > > +++ b/libavformat/flacdec.c
> > > @@ -81,8 +81,15 @@ static int flac_read_header(AVFormatContext *s)
> > >
> > > /* process metadata blocks */
> > > while (!avio_feof(s->pb) && !metadata_last) {
> > > - if (avio_read(s->pb, header, 4) != 4)
> > > - return AVERROR_INVALIDDATA;
> > > + ret = avio_read(s->pb, header, 4);
> >
> > > + if (ret != 4) {
> > > + if (ret < 0) {
> > > + goto fail;
> > > + } else {
> > > + return AVERROR_INVALIDDATA;
> > > + }
> > > + }
> >
> > this is wierd
> > because, one path goto fails the other returns directly.
>
> Oh wait now I see what you mean. buffer isn't allocated in this hunk so
> it could just as well just return. The second hunk *should* goto fail
> however. Updated patch attached
>
> I also made some test files to demonstrate the differences in behavior.
> What's being addressed here is early termination of the file. One thing
> to bikeshed over is whether to return AVERROR_EOF or
> AVERROR_INVALIDDATA in that case. The attached files demonstrate a
> change in return value depending on how short a flac file is. It might
> make more sense to always return AVERROR_EOF since being truncated is
> fundamentally the issue with the file in these cases
>
> The original intent seems mostly to just be passing error codes along
>
> /Tomas
> flacdec.c | 14 +++---
> 1 file changed, 11 insertions(+), 3 deletions(-)
> 8d27d2b37842444aad8f5df06ba02b7511ac8425
> 0011-avformat-flacdec-Return-correct-error-codes-on-read-.patch
> From 5f19fddd70417284f36421e67b92af673b7c6965 Mon Sep 17 00:00:00 2001
> From: Ulrik
> Date: Thu, 26 Jan 2023 17:51:02 +0100
> Subject: [PATCH 11/17] avformat/flacdec:Return correct error-codes on
> read-failure
>
> Forward errors from `avio_read` directly. When `avio_read` sees EOF before
> expected bytes can be read, consistently return `AVERROR_INVALIDDATA`
>
> We used to return `AVERROR(AVERROR_INVALIDDATA)` when failing to read
> metadata block headers. `AVERROR_INVALIDDATA` is already negative, so
> wrapping in `AVERROR` leads to double-negation.
>
> We used to return `AVERROR(EIO)` when failing to read extended metadata.
> However, many times, the IO-layer is not at fault, the input data is simply
> corrupted (truncated), so we return `AVERROR_INVALIDDATA` here as well.
> ---
> libavformat/flacdec.c | 14 +++---
> 1 file changed, 11 insertions(+), 3 deletions(-)
>
> diff --git a/libavformat/flacdec.c b/libavformat/flacdec.c
> index 9f65c25864..da7fbc4dea 100644
> --- a/libavformat/flacdec.c
> +++ b/libavformat/flacdec.c
> @@ -81,8 +81,13 @@ static int flac_read_header(AVFormatContext *s)
>
> /* process metadata blocks */
> while (!avio_feof(s->pb) && !metadata_last) {
> -if (avio_read(s->pb, header, 4) != 4)
> +ret = avio_read(s->pb, header, 4);
> +if (ret < 0) {
> +return ret;
> +} else if (ret != 4) {
> return AVERROR_INVALIDDATA;
> +}
> +
> flac_parse_block_header(header, &metadata_last, &metadata_type,
> &metadata_size);
> switch (metadata
[FFmpeg-devel] [PATCH] swscale/swscale_unscaled: add swscale/swscale_unscaled: add unscaled x2rgb10le to gbrp10
Signed-off-by: James Almer
---
libswscale/swscale_unscaled.c | 74 +++
tests/ref/pixfmt/gbrp10-x2bgr10le | 2 +-
tests/ref/pixfmt/gbrp10-x2rgb10le | 2 +-
3 files changed, 76 insertions(+), 2 deletions(-)
diff --git a/libswscale/swscale_unscaled.c b/libswscale/swscale_unscaled.c
index c87a70e95e..40d258b4bd 100644
--- a/libswscale/swscale_unscaled.c
+++ b/libswscale/swscale_unscaled.c
@@ -742,6 +742,63 @@ static void packed16togbra16(const uint8_t *src, int
srcStride,
}
}
+static void packed30togbra10(const uint8_t *src, int srcStride,
+ uint16_t *dst[], const int dstStride[], int
srcSliceH,
+ int swap, int width)
+{
+int x, h, i;
+int dst_alpha = dst[3] != NULL;
+for (h = 0; h < srcSliceH; h++) {
+uint32_t *src_line = (uint32_t *)(src + srcStride * h);
+
+switch (swap) {
+case 3:
+case 2:
+if (dst_alpha) {
+for (x = 0; x < width; x++) {
+unsigned pixel = AV_RL32(src_line);
+dst[0][x] = av_bswap16((pixel >> 20) & 0x3FF);
+dst[1][x] = av_bswap16((pixel >> 10) & 0x3FF);
+dst[2][x] = av_bswap16( pixel& 0x3FF);
+dst[3][x] = 0x;
+src_line++;
+}
+} else {
+for (x = 0; x < width; x++) {
+unsigned pixel = AV_RL32(src_line);
+dst[0][x] = av_bswap16((pixel >> 20) & 0x3FF);
+dst[1][x] = av_bswap16((pixel >> 10) & 0x3FF);
+dst[2][x] = av_bswap16( pixel& 0x3FF);
+src_line++;
+}
+}
+break;
+default:
+if (dst_alpha) {
+for (x = 0; x < width; x++) {
+unsigned pixel = AV_RL32(src_line);
+dst[0][x] = (pixel >> 20) & 0x3FF;
+dst[1][x] = (pixel >> 10) & 0x3FF;
+dst[2][x] = pixel& 0x3FF;
+dst[3][x] = 0x;
+src_line++;
+}
+} else {
+for (x = 0; x < width; x++) {
+unsigned pixel = AV_RL32(src_line);
+dst[0][x] = (pixel >> 20) & 0x3FF;
+dst[1][x] = (pixel >> 10) & 0x3FF;
+dst[2][x] = pixel& 0x3FF;
+src_line++;
+}
+}
+break;
+}
+for (i = 0; i < 4; i++)
+dst[i] += dstStride[i] >> 1;
+}
+}
+
static int Rgb16ToPlanarRgb16Wrapper(SwsInternal *c, const uint8_t *const
src[],
const int srcStride[], int srcSliceY, int
srcSliceH,
uint8_t *const dst[], const int
dstStride[])
@@ -785,6 +842,12 @@ static int Rgb16ToPlanarRgb16Wrapper(SwsInternal *c, const
uint8_t *const src[],
dst2013, stride2013, srcSliceH, alpha, swap,
16 - bpc, c->srcW);
break;
+case AV_PIX_FMT_X2RGB10LE:
+av_assert0(bpc == 10);
+packed30togbra10(src[0], srcStride[0],
+ dst2013, stride2013, srcSliceH, swap,
+ c->srcW);
+break;
case AV_PIX_FMT_BGR48LE:
case AV_PIX_FMT_BGR48BE:
case AV_PIX_FMT_BGRA64LE:
@@ -793,6 +856,12 @@ static int Rgb16ToPlanarRgb16Wrapper(SwsInternal *c, const
uint8_t *const src[],
dst1023, stride1023, srcSliceH, alpha, swap,
16 - bpc, c->srcW);
break;
+case AV_PIX_FMT_X2BGR10LE:
+av_assert0(bpc == 10);
+packed30togbra10(src[0], srcStride[0],
+ dst1023, stride1023, srcSliceH, swap,
+ c->srcW);
+break;
default:
av_log(c, AV_LOG_ERROR,
"unsupported conversion to planar RGB %s -> %s\n",
@@ -2301,6 +2370,11 @@ void ff_get_unscaled_swscale(SwsInternal *c)
dstFormat == AV_PIX_FMT_GBRAP16LE || dstFormat ==
AV_PIX_FMT_GBRAP16BE ))
c->convert_unscaled = Rgb16ToPlanarRgb16Wrapper;
+if (av_pix_fmt_desc_get(dstFormat)->comp[0].depth == 10 &&
+isPlanarRGB(dstFormat) && !isFloat(dstFormat) &&
+(srcFormat == AV_PIX_FMT_X2RGB10LE || srcFormat ==
AV_PIX_FMT_X2BGR10LE))
+c->convert_unscaled = Rgb16ToPlanarRgb16Wrapper;
+
if ((srcFormat == AV_PIX_FMT_GBRP9LE || srcFormat == AV_PIX_FMT_GBRP9BE
||
srcFormat == AV_PIX_FMT_GBRP16LE || srcFormat == AV_PIX_FMT_GBRP16BE
||
srcFormat == AV_PIX_FMT_GBRP10LE || srcFormat == AV_PIX_FMT_GBRP10BE
||
diff --git a/tests/ref/pixfmt/gbrp10-x2bgr10le
b/tests/ref/pixfmt/gbrp10-x2bgr10le
index 51e9c5e4f0..568039f4ae 100644
--- a/tests/ref/pixfmt/gbrp10-x2bgr10le
+++ b/tests/ref/pixfmt/gbrp10-x
[FFmpeg-devel] [PATCH v7] avcodec/jpeg2000: Fix FF_DWT97_INT to pass the conformance testing defined in ISO/IEC 15444-4
Fix for the integer version of the inverse 9-7 DWT processing
(FF_DWT97_INT, https://trac.ffmpeg.org/ticket/10123), which is activated with
`-flags +bitexact`.
I went through the code path for the DWT 9-7 transform (integer) and improved
precision to match conformance codestream.
As a result, the encoded codestream size is slightly larger for a given Q value.
For example, `-flags +bitexact -i lena.pnm -q: 20 -format j2k -y tmp.j2c`
gives 13K (HEAD) and 19K (with this patch).
This commit also updates the source and reference files for affected FATE tests.
Signed-off-by: Osamu Watanabe
---
libavcodec/jpeg2000.c| 11 +-
libavcodec/jpeg2000dec.c | 150 +--
libavcodec/jpeg2000dwt.c | 47 +++
libavcodec/jpeg2000dwt.h | 1 +
libavcodec/jpeg2000htdec.c | 9 +-
libavcodec/tests/jpeg2000dwt.c | 5 +
tests/ref/fate/j2k-dwt | 40 +++---
tests/ref/fate/jpeg2000-dcinema | 4 +-
tests/ref/fate/jpeg2000dec-p0_04 | 2 +-
tests/ref/fate/jpeg2000dec-p0_05 | 2 +-
tests/ref/fate/jpeg2000dec-p0_09 | 2 +-
tests/ref/vsynth/vsynth1-jpeg2000-97 | 8 +-
tests/ref/vsynth/vsynth2-jpeg2000-97 | 8 +-
tests/ref/vsynth/vsynth3-jpeg2000-97 | 8 +-
tests/ref/vsynth/vsynth_lena-jpeg2000-97 | 8 +-
15 files changed, 163 insertions(+), 142 deletions(-)
diff --git a/libavcodec/jpeg2000.c b/libavcodec/jpeg2000.c
index d6ffb02319..7911500901 100644
--- a/libavcodec/jpeg2000.c
+++ b/libavcodec/jpeg2000.c
@@ -260,9 +260,7 @@ static void init_band_stepsize(AVCodecContext *avctx,
band->f_stepsize *= F_LFTG_X * F_LFTG_X * 4;
break;
}
-if (codsty->transform == FF_DWT97) {
-band->f_stepsize *= pow(F_LFTG_K, 2*(codsty->nreslevels2decode -
reslevelno) + lband - 2);
-}
+band->f_stepsize *= pow(F_LFTG_K, 2*(codsty->nreslevels2decode -
reslevelno) + lband - 2);
}
if (band->f_stepsize > (INT_MAX >> 15)) {
@@ -270,12 +268,7 @@ static void init_band_stepsize(AVCodecContext *avctx,
av_log(avctx, AV_LOG_ERROR, "stepsize out of range\n");
}
-band->i_stepsize = band->f_stepsize * (1 << 15);
-
-/* FIXME: In OpenJPEG code stepsize = stepsize * 0.5. Why?
- * If not set output of entropic decoder is not correct. */
-if (!av_codec_is_encoder(avctx->codec))
-band->f_stepsize *= 0.5;
+band->i_stepsize = (int)floorf(band->f_stepsize * (1 << 15));
}
static int init_prec(AVCodecContext *avctx,
diff --git a/libavcodec/jpeg2000dec.c b/libavcodec/jpeg2000dec.c
index 5b05ff2455..c9d8b025b1 100644
--- a/libavcodec/jpeg2000dec.c
+++ b/libavcodec/jpeg2000dec.c
@@ -1885,14 +1885,15 @@ static void decode_sigpass(Jpeg2000T1Context *t1, int
width, int height,
&& !(t1->flags[(y+1) * t1->stride + x+1] & (JPEG2000_T1_SIG |
JPEG2000_T1_VIS))) {
if (ff_mqc_decode(&t1->mqc, t1->mqc.cx_states +
ff_jpeg2000_getsigctxno(t1->flags[(y+1) * t1->stride + x+1] & flags_mask,
bandno))) {
int xorbit, ctxno =
ff_jpeg2000_getsgnctxno(t1->flags[(y+1) * t1->stride + x+1] & flags_mask,
&xorbit);
-if (t1->mqc.raw)
- t1->data[(y) * t1->stride + x] =
ff_mqc_decode(&t1->mqc, t1->mqc.cx_states + ctxno) ? -mask : mask;
-else
- t1->data[(y) * t1->stride + x] =
(ff_mqc_decode(&t1->mqc, t1->mqc.cx_states + ctxno) ^ xorbit) ?
- -mask : mask;
-
+if (t1->mqc.raw) {
+t1->data[(y) * t1->stride + x] |=
ff_mqc_decode(&t1->mqc, t1->mqc.cx_states + ctxno) << 31;
+t1->data[(y) * t1->stride + x] |= mask;
+} else {
+t1->data[(y) * t1->stride + x] |=
(ff_mqc_decode(&t1->mqc, t1->mqc.cx_states + ctxno) ^ xorbit) << 31;
+t1->data[(y) * t1->stride + x] |= mask;
+}
ff_jpeg2000_set_significance(t1, x, y,
- t1->data[(y) * t1->stride
+ x] < 0);
+ t1->data[(y) * t1->stride
+ x] & INT32_MIN);
}
t1->flags[(y + 1) * t1->stride + x + 1] |= JPEG2000_T1_VIS;
}
@@ -1902,11 +1903,10 @@ static void decode_sigpass(Jpeg2000T1Context *t1, int
width, int height,
static void decode_refpass(Jpeg2000T1Context *t1, int width, int height,
int bpno, int vert_causal_ctx_csty_symbol)
{
-int phalf, nhalf;
+int phalf;
int y0, x, y;
phalf = 1 << (bpno - 1);
-nhalf = -phalf;
for (y0 = 0; y0 < height; y0 += 4)
for (x = 0; x < width; x++)
@@ -1915,10 +1915,13
Re: [FFmpeg-devel] [PATCH V6] Patch to add interlaced HEVC decoding to HEVCDEC
On Thu, Oct 31, 2024 at 01:45:12PM -0500, Jose Santiago wrote: [...] > hevcdec.c | 24 +++ > hevcdec.h | 13 + > refs.c| 417 > -- > sei.c | 16 -- > sei.h | 129 ++- > 5 files changed, 574 insertions(+), 25 deletions(-) > b16cf1b2ee73f1e28aa4d95c6180a1e4b43a515d > ffmpeg-7.2-dev-0001-hevcdec-interlaced-v6.git.patch > From 14b950ad54a6b4ba9274769328fc32dc29e6efae Mon Sep 17 00:00:00 2001 > From: Jose Santiago > Date: Thu, 31 Oct 2024 13:38:57 -0500 > Subject: [PATCH] uncommited > > --- > libavcodec/hevc/hevcdec.c | 24 ++- > libavcodec/hevc/hevcdec.h | 13 ++ > libavcodec/hevc/refs.c| 417 +- > libavcodec/hevc/sei.c | 16 +- > libavcodec/hevc/sei.h | 129 +++- > 5 files changed, 574 insertions(+), 25 deletions(-) this breaks fate, also the commit message doesnt look right TESThevc-conformance-AMP_A_Samsung_6 --- ./tests/ref/fate/hevc-conformance-AMP_A_Samsung_6 2024-10-26 00:34:57.668301802 +0200 +++ tests/data/fate/hevc-conformance-AMP_A_Samsung_62024-11-02 19:54:36.323416171 +0100 @@ -62,4 +62,3 @@ 0, 56, 56,1, 6144000, 0xc48a4f6b 0, 57, 57,1, 6144000, 0xecb27957 0, 58, 58,1, 6144000, 0xe2ec6e92 -0, 59, 59,1, 6144000, 0x94697078 Test hevc-conformance-AMP_A_Samsung_6 failed. Look at tests/data/fate/hevc-conformance-AMP_A_Samsung_6.err for details. make: *** [tests/Makefile:315: fate-hevc-conformance-AMP_A_Samsung_6] Error 1 thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The bravest are surely those who have the clearest vision of what is before them, glory and danger alike, and yet notwithstanding go out to meet it. -- Thucydides signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] fftools/ffplay: fix crash when vk renderer is null
My patch formatting was broken by my email client, and I resent it, but it
created a new thread in the mailing list. Please let me know if I should resent
it as a reply on the same thread.
31 Oct 2024 19:54:51 Michael Niedermayer :
> On Thu, Oct 31, 2024 at 02:40:57PM +0100, Leandro Santiago wrote:
>> When vulkan rendering is requested by the user and fails, ffplay should
>> exit graciously instead of crash due to a null pointer deref.
>>
>> Signed-off-by: Leandro Santiago
>> ---
>> fftools/ffplay.c | 5 +
>> 1 file changed, 5 insertions(+)
>>
>> diff --git a/fftools/ffplay.c b/fftools/ffplay.c
>> index a596972769..56d0a36ca1 100644
>> --- a/fftools/ffplay.c
>> +++ b/fftools/ffplay.c
>> @@ -2612,6 +2612,11 @@ static int create_hwaccel(AVBufferRef **device_ctx)
>> if (type == AV_HWDEVICE_TYPE_NONE)
>> return AVERROR(ENOTSUP);
>> + if (!vk_renderer) {
>> + av_log(NULL, AV_LOG_ERROR, "Vulkan renderer is not available\n");
>
> there is something wrong with this patch
> the "+" shouldnt be in teh 2nd column
>
> thx
>
> [...]
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> "Nothing to hide" only works if the folks in power share the values of
> you and everyone you know entirely and always will -- Tom Scott
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] fate/pixfmts: add an 8bits variant of the new tests
Signed-off-by: James Almer
---
tests/fate-run.sh | 10 ++
tests/fate/pixfmt.mak | 28
tests/ref/pixfmt/gbrp-bgr24 | 2 ++
tests/ref/pixfmt/gbrp-gray| 2 ++
tests/ref/pixfmt/gbrp-monob | 2 ++
tests/ref/pixfmt/gbrp-monow | 2 ++
tests/ref/pixfmt/gbrp-rgb24 | 2 ++
tests/ref/pixfmt/gbrp-rgb32 | 2 ++
tests/ref/pixfmt/gbrp-rgb555 | 2 ++
tests/ref/pixfmt/gbrp-rgb565 | 2 ++
tests/ref/pixfmt/gbrp-xyz12le | 2 ++
tests/ref/pixfmt/gbrp-yuv410p | 2 ++
tests/ref/pixfmt/gbrp-yuv411p | 2 ++
tests/ref/pixfmt/gbrp-yuv420p | 2 ++
tests/ref/pixfmt/gbrp-yuv422p | 2 ++
tests/ref/pixfmt/gbrp-yuv440p | 2 ++
tests/ref/pixfmt/gbrp-yuv444p | 2 ++
tests/ref/pixfmt/gbrp-yuvj420p| 2 ++
tests/ref/pixfmt/gbrp-yuvj422p| 2 ++
tests/ref/pixfmt/gbrp-yuvj440p| 2 ++
tests/ref/pixfmt/gbrp-yuvj444p| 2 ++
tests/ref/pixfmt/gbrp-yuyv422 | 2 ++
tests/ref/pixfmt/yuv444p-bgr24| 2 ++
tests/ref/pixfmt/yuv444p-gray | 2 ++
tests/ref/pixfmt/yuv444p-monob| 2 ++
tests/ref/pixfmt/yuv444p-monow| 2 ++
tests/ref/pixfmt/yuv444p-rgb24| 2 ++
tests/ref/pixfmt/yuv444p-rgb32| 2 ++
tests/ref/pixfmt/yuv444p-rgb555 | 2 ++
tests/ref/pixfmt/yuv444p-rgb565 | 2 ++
tests/ref/pixfmt/yuv444p-xyz12le | 2 ++
tests/ref/pixfmt/yuv444p-yuv410p | 2 ++
tests/ref/pixfmt/yuv444p-yuv411p | 2 ++
tests/ref/pixfmt/yuv444p-yuv420p | 2 ++
tests/ref/pixfmt/yuv444p-yuv422p | 2 ++
tests/ref/pixfmt/yuv444p-yuv440p | 2 ++
tests/ref/pixfmt/yuv444p-yuv444p | 2 ++
tests/ref/pixfmt/yuv444p-yuvj420p | 2 ++
tests/ref/pixfmt/yuv444p-yuvj422p | 2 ++
tests/ref/pixfmt/yuv444p-yuvj440p | 2 ++
tests/ref/pixfmt/yuv444p-yuvj444p | 2 ++
tests/ref/pixfmt/yuv444p-yuyv422 | 2 ++
42 files changed, 106 insertions(+), 12 deletions(-)
create mode 100644 tests/ref/pixfmt/gbrp-bgr24
create mode 100644 tests/ref/pixfmt/gbrp-gray
create mode 100644 tests/ref/pixfmt/gbrp-monob
create mode 100644 tests/ref/pixfmt/gbrp-monow
create mode 100644 tests/ref/pixfmt/gbrp-rgb24
create mode 100644 tests/ref/pixfmt/gbrp-rgb32
create mode 100644 tests/ref/pixfmt/gbrp-rgb555
create mode 100644 tests/ref/pixfmt/gbrp-rgb565
create mode 100644 tests/ref/pixfmt/gbrp-xyz12le
create mode 100644 tests/ref/pixfmt/gbrp-yuv410p
create mode 100644 tests/ref/pixfmt/gbrp-yuv411p
create mode 100644 tests/ref/pixfmt/gbrp-yuv420p
create mode 100644 tests/ref/pixfmt/gbrp-yuv422p
create mode 100644 tests/ref/pixfmt/gbrp-yuv440p
create mode 100644 tests/ref/pixfmt/gbrp-yuv444p
create mode 100644 tests/ref/pixfmt/gbrp-yuvj420p
create mode 100644 tests/ref/pixfmt/gbrp-yuvj422p
create mode 100644 tests/ref/pixfmt/gbrp-yuvj440p
create mode 100644 tests/ref/pixfmt/gbrp-yuvj444p
create mode 100644 tests/ref/pixfmt/gbrp-yuyv422
create mode 100644 tests/ref/pixfmt/yuv444p-bgr24
create mode 100644 tests/ref/pixfmt/yuv444p-gray
create mode 100644 tests/ref/pixfmt/yuv444p-monob
create mode 100644 tests/ref/pixfmt/yuv444p-monow
create mode 100644 tests/ref/pixfmt/yuv444p-rgb24
create mode 100644 tests/ref/pixfmt/yuv444p-rgb32
create mode 100644 tests/ref/pixfmt/yuv444p-rgb555
create mode 100644 tests/ref/pixfmt/yuv444p-rgb565
create mode 100644 tests/ref/pixfmt/yuv444p-xyz12le
create mode 100644 tests/ref/pixfmt/yuv444p-yuv410p
create mode 100644 tests/ref/pixfmt/yuv444p-yuv411p
create mode 100644 tests/ref/pixfmt/yuv444p-yuv420p
create mode 100644 tests/ref/pixfmt/yuv444p-yuv422p
create mode 100644 tests/ref/pixfmt/yuv444p-yuv440p
create mode 100644 tests/ref/pixfmt/yuv444p-yuv444p
create mode 100644 tests/ref/pixfmt/yuv444p-yuvj420p
create mode 100644 tests/ref/pixfmt/yuv444p-yuvj422p
create mode 100644 tests/ref/pixfmt/yuv444p-yuvj440p
create mode 100644 tests/ref/pixfmt/yuv444p-yuvj444p
create mode 100644 tests/ref/pixfmt/yuv444p-yuyv422
diff --git a/tests/fate-run.sh b/tests/fate-run.sh
index 2b8d535daf..ef9c7ef064 100755
--- a/tests/fate-run.sh
+++ b/tests/fate-run.sh
@@ -203,7 +203,8 @@ enc_dec_pcm(){
ffmpeg -auto_conversion_filters -bitexact -i ${encfile} -c:a
pcm_${pcm_fmt} -fflags +bitexact -f ${dec_fmt} -
}
-FLAGS="-flags +bitexact -sws_flags +accurate_rnd+bitexact -fflags +bitexact"
+SCALE_FLAGS="+accurate_rnd+bitexact"
+FLAGS="-flags +bitexact -sws_flags $SCALE_FLAGS -fflags +bitexact"
DEC_OPTS="-threads $threads -thread_type $thread_type -idct simple $FLAGS"
ENC_OPTS="-threads 1-idct simple -dct fastint"
@@ -335,7 +336,7 @@ echov(){
}
AVCONV_OPTS="-nostdin -nostats -noauto_conversion_filters -y -cpuflags
$cpuflags -filter_threads $threads"
-COMMON_OPTS="-flags +bitexact -idct simple -sws_flags +accurate_rnd+bitexact
-fflags +bitexact"
+COMMON_OPTS="-flags +bitexact -idct simple -sws_flags $SCALE_FLAGS -fflags
+bitexact"
DEC_OPTS="$COMMON_OPTS -threads $threads"
ENC_OPTS="$COMMON_OPTS -threads 1 -dct fastint"
@@
Re: [FFmpeg-devel] [PATCH] fate: use rawvideo muxer for filter and pixel format tests
On 10/31/2024 4:22 PM, James Almer wrote: Using NUT is not ideal as not all these pixel formats have a defined fourcc in the NUT spec, and we don't care about encapsulation, only actual pixel output. Will apply soon unless someone objects. OpenPGP_signature.asc Description: OpenPGP digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avcodec/jpegxl_parser: check entropy_decoder_read_symbol return value
Hi On Fri, Nov 01, 2024 at 01:50:38PM +0100, Kacper Michajłow wrote: > Found by OSS-Fuzz. > > Signed-off-by: Kacper Michajłow > --- > libavcodec/jpegxl_parser.c | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) patch makes sense, ill leave to Leo Izen to apply, as its his code but if he isnt around, ping me and ill do it thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Many things microsoft did are stupid, but not doing something just because microsoft did it is even more stupid. If everything ms did were stupid they would be bankrupt already. signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
