[FFmpeg-devel] [PATCH] tests: Add libpostproc blocktest
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Michael Niedermayer
---
libpostproc/Makefile | 2 +
libpostproc/tests/blocktest.c | 112 +
tests/Makefile| 1 +
tests/fate/libpostproc.mak| 6 +
tests/ref/fate/blocktest | 300 ++
5 files changed, 421 insertions(+)
create mode 100644 libpostproc/tests/blocktest.c
create mode 100644 tests/fate/libpostproc.mak
create mode 100644 tests/ref/fate/blocktest
diff --git a/libpostproc/Makefile b/libpostproc/Makefile
index 77c2b6b0160..5afd2d2ad48 100644
--- a/libpostproc/Makefile
+++ b/libpostproc/Makefile
@@ -11,3 +11,5 @@ OBJS = postprocess.o \
# Windows resource file
SHLIBOBJS-$(HAVE_GNU_WINDRES) += postprocres.o
+
+TESTPROGS = blocktest
diff --git a/libpostproc/tests/blocktest.c b/libpostproc/tests/blocktest.c
new file mode 100644
index 000..f61132f93aa
--- /dev/null
+++ b/libpostproc/tests/blocktest.c
@@ -0,0 +1,112 @@
+/*
+ * Copyright (c) 2025 Michael Niedermayer
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include "libavutil/frame.h"
+#include "libavutil/adler32.h"
+#include "libpostproc/postprocess.h"
+
+typedef const uint8_t *cuint8;
+
+static void blocks(AVFrame *frame, int blocksize, int mul)
+{
+for(int y=0; yheight; y++) {
+for(int x=0; xwidth; x++) {
+frame->data[0][x + y*frame->linesize[0]] = x/blocksize*mul +
y/blocksize*mul;
+}
+}
+for(int y=0; y<(frame->height+1)/2; y++) {
+for(int x=0; x<(frame->width+1)/2; x++) {
+frame->data[1][x + y*frame->linesize[1]] = x/blocksize*mul +
y/blocksize*mul;
+frame->data[2][x + y*frame->linesize[2]] = x/blocksize *
(y/blocksize)*mul;
+}
+}
+}
+
+static int64_t chksum(AVFrame *f)
+{
+AVAdler a = 123;
+
+for(int y=0; yheight; y++) {
+a = av_adler32_update(a, &f->data[0][y*f->linesize[0]], f->width);
+}
+for(int y=0; y<(f->height+1)/2; y++) {
+a = av_adler32_update(a, &f->data[1][y*f->linesize[1]],
(f->width+1)/2);
+a = av_adler32_update(a, &f->data[2][y*f->linesize[2]],
(f->width+1)/2);
+}
+
+return a;
+}
+
+static int64_t test(int width, int height, int blocksize, int flags, int
pict_type, int quality) {
+AVFrame *in = av_frame_alloc();
+AVFrame *out = av_frame_alloc();
+pp_context *context = pp_get_context(width, height, flags);
+pp_mode *mode = pp_get_mode_by_name_and_quality("de", quality);
+int64_t ret;
+
+if (!in || !out || !context || !mode) {
+ret = AVERROR(ENOMEM);
+goto end;
+}
+
+in-> width = out->width = width;
+in->height = out->height = height;
+in->format = out->format = AV_PIX_FMT_YUV420P;
+
+ret = av_frame_get_buffer(in, 0);
+if (ret < 0)
+goto end;
+
+ret = av_frame_get_buffer(out, 0);
+if (ret < 0)
+goto end;
+
+blocks(in, blocksize, 11);
+
+pp_postprocess( (cuint8[]){in->data[0], in->data[1], in->data[2]},
in->linesize,
+ out->data, out->linesize,
+ width, height, NULL, 0,
+ mode, context, pict_type);
+
+ret = chksum(out);
+end:
+av_frame_free(&in);
+av_frame_free(&out);
+pp_free_context(context);
+pp_free_mode(mode);
+
+return ret;
+}
+
+int main(int argc, char **argv) {
+
+for (int w=8; w< 352; w=w*3-1) {
+for (int h=8; h< 352; h=h*5-7) {
+for (int b=1; b<17; b*=2) {
+for (int q=0; q<17; q = 2*q+1) {
+int64_t ret = test(352, 288, b, PP_FORMAT_420, 0, q);
+printf("blocktest %dx%d b:%d q:%d result %"PRIX64"\n", w,
h, b, q, ret);
+}
+}
+}
+}
+
+return 0;
+}
diff --git a/tests/Makefile b/tests/Makefile
index f9f5fc07f3b..0c08f687130 100644
--- a/tests/Makefile
+++ b/tests/Makefile
@@ -207,6 +207,7 @@ include $(SRC_PATH)/tests/fate/libavformat.mak
include $(SRC_PATH)/tests/fate/libavutil.mak
include $(SRC_PATH)/tests/fate/libswresample.mak
include $(SRC_PATH)/tests/fate/libswscale.mak
+include $(SRC_PATH)/tests/fate/libpostproc.mak
include $(SRC_PATH)/tests/fate/lossless-audio.mak
include $(SRC_PATH)/tests/fate/lossless-video.ma
Re: [FFmpeg-devel] [PATCH v8 0/4] print_graphs: Complete Filtergraph Printing
In date Monday 2025-03-31 19:27:13 +, softworkz . wrote: [...] > > I'm fine with the changes assuming it passes fate. > > > > I don't know if you have push commit rights, if needed I will locally > > test and push them after a few days to let other developers to > > comment. > > Hi Stefano, > > I have push access set up freshly now. Shall I push it myself (after > a last call) or do you want to do it? I'm happy if you can push that yourself, so there are less chances I can get things wrong when pulling the patches from the ML. As I said, I'm fine with the patches assuming they pass FATE, and we can improve/fix things on top of them. Thanks. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avutil/dict: fix memleak in av_dict_set()
Hi James
On Mon, Apr 07, 2025 at 07:45:23PM -0300, James Almer wrote:
> Regression since 19e9a203b7b8e613840b055cdf68303a4fb84581.
>
> Signed-off-by: James Almer
> ---
> libavutil/dict.c | 19 ++-
> 1 file changed, 10 insertions(+), 9 deletions(-)
>
> diff --git a/libavutil/dict.c b/libavutil/dict.c
> index f7dcd07eeb..fafb454fd3 100644
> --- a/libavutil/dict.c
> +++ b/libavutil/dict.c
> @@ -99,27 +99,28 @@ int av_dict_set(AVDictionary **pm, const char *key, const
> char *value,
> err = AVERROR(EINVAL);
> goto err_out;
> }
> +if (flags & AV_DICT_DONT_STRDUP_KEY)
> +copy_key = (void *)key;
> +else
> +copy_key = av_strdup(key);
> +if (!copy_key || (value && !copy_value))
> +goto enomem;
> +
> if (!(flags & AV_DICT_MULTIKEY)) {
> tag = av_dict_get(m, key, NULL, flags);
> } else if (flags & AV_DICT_DEDUP) {
> while ((tag = av_dict_get(m, key, tag, flags))) {
> if ((!value && !tag->value) ||
> (value && tag->value && !strcmp(value, tag->value))) {
> -if (flags & AV_DICT_DONT_STRDUP_KEY)
> -av_free((void*)key);
> -if (flags & AV_DICT_DONT_STRDUP_VAL)
> -av_free((void*)value);
> +av_free(copy_key);
> +av_free(copy_value);
> return 0;
> }
> }
> }
> -if (flags & AV_DICT_DONT_STRDUP_KEY)
> -copy_key = (void *)key;
> -else
> -copy_key = av_strdup(key);
Should be ok
Maybe slightly better if the strdup isnt moved up as theres
a case then where we strdup and free it.
thx
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Those who are best at talking, realize last or never when they are wrong.
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] SW's Patchsets Overview
Marton Balint (HE12025-04-06): > I think a log flag to completely hide the addresses makes sense, and can be > implemented cleanly and reliably in avutil/log. I can totally support that. I do not. The more I think on it, the more I consider this whole endeavour is completely misguided. One of our guiding principles is that the console output of our command-line tools should be, by default, usable by experienced users. This is why we reject proposals to hide the banner by default, and this is why we should not do this either. Regards, -- Nicolas George ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] SW's Patchsets Overview
> -Original Message- > From: ffmpeg-devel On Behalf Of > Nicolas George > Sent: Montag, 7. April 2025 11:14 > To: FFmpeg development discussions and patches > Subject: Re: [FFmpeg-devel] SW's Patchsets Overview > > Marton Balint (HE12025-04-06): > > I think a log flag to completely hide the addresses makes sense, and > can be > > implemented cleanly and reliably in avutil/log. I can totally support > that. > > I do not. The more I think on it, the more I consider this whole > endeavour is completely misguided. > > One of our guiding principles is that the console output of our > command-line tools should be, by default, usable by experienced users. > This is why we reject proposals to hide the banner by default, and this > is why we should not do this either. > > Regards, > > -- > Nicolas George > ___ Hi Nicolas, had a bad sleep? Misguided? Our "guiding principles" involve outputting tons of meaningless numbers? The analogon you are trying to draw is comparing apples and oranges. Besides - no matter how experienced a user may be - as long as the one doesn't have access to any kind of debugging tool, those memory addresses are largely useless (excepting the small value of discriminability that my original patchset is retaining in the form of "simple IDs"). Beyond those use cases, anybody claiming those numbers being of value for oneself, being an experienced user, would be nothing more than a pretender. sw PS: As far as I'm concerned: I did have a bad sleep. Next time I'll try to be friendly again, even though it's hard after reading such nonsense. ___ ffmpeg-devel mailing list ffmpeg-devel@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] GSoC 2025 Contributor Application deadline
Hi Everyone April 8 - 18:00 UTC is GSoC contributor application deadline If you are a contributor make sure you submit your application before that If you are a mentor make sure contributors you are working with are aware of this, in case there are any who have not submitted their application yet thx -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Any man who breaks a law that conscience tells him is unjust and willingly accepts the penalty by staying in jail in order to arouse the conscience of the community on the injustice of the law is at that moment expressing the very highest respect for law. - Martin Luther King Jr signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 4/4] avcodec/ffv1enc: avoid slices larger than 360x288 if no value is specified
On Sun, Apr 06, 2025 at 10:13:23PM -0300, James Almer wrote: > On 4/6/2025 8:44 PM, Michael Niedermayer wrote: > > On Sun, Apr 06, 2025 at 08:29:42PM -0300, James Almer wrote: > > > On 4/3/2025 7:50 AM, Michael Niedermayer wrote: > > > > This improves speed by providing more independent things for more CPUs > > > > > > > > Signed-off-by: Michael Niedermayer > > > > --- > > > >libavcodec/ffv1enc.c | 6 +- > > > >.../ref/fate/matroska-mastering-display-metadata | 16 > > > > > > > >2 files changed, 13 insertions(+), 9 deletions(-) > > > > > > > > diff --git a/libavcodec/ffv1enc.c b/libavcodec/ffv1enc.c > > > > index ce3f8e023e5..221344794e2 100644 > > > > --- a/libavcodec/ffv1enc.c > > > > +++ b/libavcodec/ffv1enc.c > > > > @@ -581,7 +581,11 @@ int ff_ffv1_encode_determine_slices(AVCodecContext > > > > *avctx) > > > >if ( ff_need_new_slices(avctx->width , > > > > s->num_h_slices, s->chroma_h_shift) > > > >||ff_need_new_slices(avctx->height, > > > > s->num_v_slices, s->chroma_v_shift)) > > > >continue; > > > > -if (avctx->slices == s->num_h_slices * s->num_v_slices && > > > > avctx->slices <= MAX_SLICES || !avctx->slices) > > > > +if (avctx->slices == s->num_h_slices * s->num_v_slices && > > > > avctx->slices <= MAX_SLICES) > > > > +return 0; > > > > +if (maxw*maxh > 360*288) > > > > +continue; > > > > +if (!avctx->slices) > > > >return 0; > > > >} > > > >} > > > > diff --git a/tests/ref/fate/matroska-mastering-display-metadata > > > > b/tests/ref/fate/matroska-mastering-display-metadata > > > > index 91ce6a05584..6a2ff15b1b2 100644 > > > > --- a/tests/ref/fate/matroska-mastering-display-metadata > > > > +++ b/tests/ref/fate/matroska-mastering-display-metadata > > > > @@ -1,7 +1,7 @@ > > > > -ad5e3c4e338599c81ef7d0f9ae25f871 > > > > *tests/data/fate/matroska-mastering-display-metadata.matroska > > > > -1669589 tests/data/fate/matroska-mastering-display-metadata.matroska > > > > +c1e5e2ecf433cf05af8556debc7d4d0b > > > > *tests/data/fate/matroska-mastering-display-metadata.matroska > > > > +1669773 tests/data/fate/matroska-mastering-display-metadata.matroska > > > >#extradata 0:4, 0x040901a3 > > > > -#extradata 3: 200, 0x506463a8 > > > > +#extradata 3: 202, 0xfce96279 > > > > > > Why did extradata change? Slice dimension value changes? > > > > yes, any reason you belive theres an issue ? > > No, just wanted to know why the size of extradata changed. yes, 1280x720 used 2x2 slice configuration before and now uses 3x3 2x2 is stored as storing the value 1 twice and 3x3 stores the value 2 twice thats 4 range coded binary values more in the bitstream. Its a bit surprising that these end up needing 2 bytes more though but its possible if most of the other stuff is "1" and not "2" values than the cost of storing a "2" can be higher thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Never trust a computer, one day, it may think you are the virus. -- Compn signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 2/2] avutil/x86/aes: remove a few branches
The rounds value is constant and can be one of three hardcoded values, so
instead of checking it on every loop, just split the function into three
different implementations for each value.
Before:
aes_decrypt_128_aesni: 93.8 (47.58x)
aes_decrypt_192_aesni: 106.9 (49.30x)
aes_decrypt_256_aesni: 109.8 (56.50x)
aes_encrypt_128_aesni: 93.2 (47.70x)
aes_encrypt_192_aesni: 111.1 (48.36x)
aes_encrypt_256_aesni: 113.6 (56.27x)
After:
aes_decrypt_128_aesni: 71.5 (63.31x)
aes_decrypt_192_aesni: 96.8 (55.64x)
aes_decrypt_256_aesni: 106.1 (58.51x)
aes_encrypt_128_aesni: 81.3 (55.92x)
aes_encrypt_192_aesni: 91.2 (59.78x)
aes_encrypt_256_aesni: 109.0 (58.26x)
Signed-off-by: James Almer
---
libavutil/aes.c | 3 +--
libavutil/x86/aes.asm| 24 +---
libavutil/x86/aes_init.c | 22 ++
3 files changed, 32 insertions(+), 17 deletions(-)
diff --git a/libavutil/aes.c b/libavutil/aes.c
index 5f31412149..52a250bc00 100644
--- a/libavutil/aes.c
+++ b/libavutil/aes.c
@@ -234,6 +234,7 @@ int av_aes_init(AVAES *a, const uint8_t *key, int key_bits,
int decrypt)
int KC = key_bits >> 5;
int rounds = KC + 6;
+a->rounds = rounds;
a->crypt = decrypt ? aes_decrypt : aes_encrypt;
if (ARCH_X86)
ff_init_aes_x86(a, decrypt);
@@ -243,8 +244,6 @@ int av_aes_init(AVAES *a, const uint8_t *key, int key_bits,
int decrypt)
if (key_bits != 128 && key_bits != 192 && key_bits != 256)
return AVERROR(EINVAL);
-a->rounds = rounds;
-
memcpy(tk, key, KC * 4);
memcpy(a->round_key[0].u8, key, KC * 4);
diff --git a/libavutil/x86/aes.asm b/libavutil/x86/aes.asm
index 7084c46055..e985a94685 100644
--- a/libavutil/x86/aes.asm
+++ b/libavutil/x86/aes.asm
@@ -26,12 +26,11 @@ SECTION .text
; void ff_aes_decrypt(AVAES *a, uint8_t *dst, const uint8_t *src,
; int count, uint8_t *iv, int rounds)
;-
-%macro AES_CRYPT 1
-cglobal aes_%1rypt, 6,6,2
+%macro AES_CRYPT 2
+cglobal aes_%1rypt_%2, 5, 5, 2
test r3d, r3d
je .ret
shl r3d, 4
-add r5d, r5d
add r0, 0x60
add r2, r3
add r1, r3
@@ -45,16 +44,15 @@ cglobal aes_%1rypt, 6,6,2
%ifidn %1, enc
pxor m0, m1
%endif
-pxor m0, [r0+8*r5-0x60]
-cmp r5d, 24
-je .rounds12
-jl .rounds10
+pxor m0, [r0+8*2*%2-0x60]
+%if %2 > 12
aes%1 m0, [r0+0x70]
aes%1 m0, [r0+0x60]
-.rounds12:
+%endif
+%if %2 > 10
aes%1 m0, [r0+0x50]
aes%1 m0, [r0+0x40]
-.rounds10:
+%endif
aes%1 m0, [r0+0x30]
aes%1 m0, [r0+0x20]
aes%1 m0, [r0+0x10]
@@ -90,6 +88,10 @@ cglobal aes_%1rypt, 6,6,2
%if HAVE_AESNI_EXTERNAL
INIT_XMM aesni
-AES_CRYPT enc
-AES_CRYPT dec
+AES_CRYPT enc, 10
+AES_CRYPT enc, 12
+AES_CRYPT enc, 14
+AES_CRYPT dec, 10
+AES_CRYPT dec, 12
+AES_CRYPT dec, 14
%endif
diff --git a/libavutil/x86/aes_init.c b/libavutil/x86/aes_init.c
index 0ac8c20239..c3e2003c07 100644
--- a/libavutil/x86/aes_init.c
+++ b/libavutil/x86/aes_init.c
@@ -22,15 +22,29 @@
#include "libavutil/aes_internal.h"
#include "libavutil/x86/cpu.h"
-void ff_aes_decrypt_aesni(AVAES *a, uint8_t *dst, const uint8_t *src,
+void ff_aes_decrypt_10_aesni(AVAES *a, uint8_t *dst, const uint8_t *src,
int count, uint8_t *iv, int rounds);
-void ff_aes_encrypt_aesni(AVAES *a, uint8_t *dst, const uint8_t *src,
+void ff_aes_decrypt_12_aesni(AVAES *a, uint8_t *dst, const uint8_t *src,
int count, uint8_t *iv, int rounds);
+void ff_aes_decrypt_14_aesni(AVAES *a, uint8_t *dst, const uint8_t *src,
+ int count, uint8_t *iv, int rounds);
+void ff_aes_encrypt_10_aesni(AVAES *a, uint8_t *dst, const uint8_t *src,
+ int count, uint8_t *iv, int rounds);
+void ff_aes_encrypt_12_aesni(AVAES *a, uint8_t *dst, const uint8_t *src,
+ int count, uint8_t *iv, int rounds);
+void ff_aes_encrypt_14_aesni(AVAES *a, uint8_t *dst, const uint8_t *src,
+ int count, uint8_t *iv, int rounds);
void ff_init_aes_x86(AVAES *a, int decrypt)
{
int cpu_flags = av_get_cpu_flags();
-if (EXTERNAL_AESNI(cpu_flags))
-a->crypt = decrypt ? ff_aes_decrypt_aesni : ff_aes_encrypt_aesni;
+if (EXTERNAL_AESNI(cpu_flags)) {
+if (a->rounds == 10)
+a->crypt = decrypt ? ff_aes_decrypt_10_aesni :
ff_aes_encrypt_10_aesni;
+else if (a->rounds == 12)
+a-
Re: [FFmpeg-devel] [PATCH v1] avcodec/evc_decoder: Fix pixel format handling in export_stream_params function
Andreas, what about my patch? I submitted a fix some time ago
(https://patchwork.ffmpeg.org/project/ffmpeg/patch/20250325085030.1306501-1-
d.kozin...@samsung.com/_ .
Is there still something wrong?
I'm waiting for some feedback.
We would like to close the topic now.
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> Andreas Rheinhardt
> Sent: wtorek, 25 marca 2025 09:18
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH v1] avcodec/evc_decoder: Fix pixel
format
> handling in export_stream_params function
>
> Dawid Kozinski:
> > Signed-off-by: Dawid Kozinski
> > ---
> > libavcodec/libxevd.c | 12
> > 1 file changed, 8 insertions(+), 4 deletions(-)
> >
> > diff --git a/libavcodec/libxevd.c b/libavcodec/libxevd.c index
> > 520fdab7d8..483700c81e 100644
> > --- a/libavcodec/libxevd.c
> > +++ b/libavcodec/libxevd.c
> > @@ -152,16 +152,20 @@ static int export_stream_params(const XevdContext
> *xectx, AVCodecContext *avctx)
> > }
> > switch(color_space) {
> > case XEVD_CS_YCBCR400_10LE:
> > -avctx->pix_fmt = AV_PIX_FMT_GRAY10LE;
> > +case XEVD_CS_SET(XEVD_CF_YCBCR400, 10, 1): //
> XEVD_CS_YCBCR400_10BE
> > +avctx->pix_fmt = AV_PIX_FMT_GRAY10;
> > break;
> > case XEVD_CS_YCBCR420_10LE:
> > -avctx->pix_fmt = AV_PIX_FMT_YUV420P10LE;
> > +case XEVD_CS_SET(XEVD_CF_YCBCR420, 10, 1): //
> XEVD_CS_YCBCR420_10BE
> > +avctx->pix_fmt = AV_PIX_FMT_YUV420P10;
> > break;
> > case XEVD_CS_YCBCR422_10LE:
> > -avctx->pix_fmt = AV_PIX_FMT_YUV422P10LE;
> > +case XEVD_CS_SET(XEVD_CF_YCBCR422, 10, 1): //
> XEVD_CS_YCBCR422_10BE
> > +avctx->pix_fmt = AV_PIX_FMT_YUV422P10;
> > break;
> > case XEVD_CS_YCBCR444_10LE:
> > -avctx->pix_fmt = AV_PIX_FMT_YUV444P10LE;
> > +case XEVD_CS_SET(XEVD_CF_YCBCR444, 10, 1): //
> XEVD_CS_YCBCR444_10BE
> > +avctx->pix_fmt = AV_PIX_FMT_YUV444P10;
> > break;
> > default:
> > av_log(avctx, AV_LOG_ERROR, "Unknown color space\n");
>
> This patch maps both BE and LE formats to FFmpeg's corresponding native
> endian formats. This is wrong.
>
> - Andreas
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://protect2.fireeye.com/v1/url?k=f6892c97-970239ad-f688a7d8-
> 74fe4860008a-8439094af49407cb&q=1&e=cc888bcc-836f-4cab-acb4-
> a2034e7875c6&u=https%3A%2F%2Fffmpeg.org%2Fmailman%2Flistinfo%2Fffmp
> eg-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".
