Re: [FFmpeg-devel] [PATCH] lavfi/drawtext: Add localtime_ms for millisecond precision
вт, 8 июн. 2021 г., 19:57 Thilo Borgmann : > Am 08.06.21 um 18:52 schrieb Valerii Zapodovnikov: > > Oh, so it worked on patchwork? Strnge, okay then. No need to. > > Please read [1] and [2]. Please keep all old text and do inline-commenting. > > -Thilo > No. > > [1] http://ffmpeg.org/developer.html > [2] http://ffmpeg.org/mailing-list-faq.html > ___ > 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] lavfi/drawtext: Add localtime_ms for millisecond precision
Oh, so it worked on patchwork? Strnge, okay then. No need to. ___ 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] lavfi/drawtext: Add localtime_ms for millisecond precision
Plese resend it in new thread but rename it to .txt. 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] fftools/ffplay: 240M matrix is not the same as BT.601
Wait a second. SDL_SetYUVConversionMode does not support 444? You are setting it to mode = SDL_YUV_CONVERSION_AUTOMATIC if it is 444, which I suppose works on just the size of frame? Then this cannot be fixed, I suppose? There is a workround above, as I said. ___ 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] libavcodec: r12b decoder
BTW, who knows how to show warnings on make job on patchwork? Only if make fate fails you can see it, but not otherwise. Also, md5 warnings, when you are going to fix those?? https://patchwork.ffmpeg.org/project/ffmpeg/patch/CAPUCmECSxQwMtttmRqTC-JtOpcfUB9SVQ8ZPZOHULFL9=2d...@mail.gmail.com/ ___ 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: 240M matrix is not the same as BT.601
вт, 8 июн. 2021 г., 5:28 Michael Bradshaw : > I'll just chime in and say: > > FIXME comments aren't that helpful. It would be more helpful to av_log when > you detect you've hit an unsupported situation. > How should I know what are unsupported situations? I mean sure, sYCC (BT.709 primaries with BT.601 matrix and sRGB transfer) is such a case, but I am not sure what else and it is impossible to detect it (also BT.601 matrix with classic BT.601/709/2020 transfer and SMPTE C primaries, like on trac)). Because were it possible, I would have JUST FIXED IT. Also, that will still be not enough as primaries must be also color managed, except ffplay does not support color managment. BT.601 matrix vs BT.709 matrix vs BT.2020-ncl matrix is not all, I hope you understand that. With the case BT.2020-ncl it is not it that make it that bad for BT.2100 (HDR). It is PQ transfer function. Not even primaries. As for SMPTE 240M vs BT.601 Y'CbCr matrices: yes, they're different. But > SDL doesn't support SMPTE 240M. It only supports: > Yes, I know that. Can you imagine?? Oh, my. > SDL_YUV_CONVERSION_JPEG, /**< Full range JPEG */ > SDL_YUV_CONVERSION_BT601, /**< BT.601 (the default) */ > SDL_YUV_CONVERSION_BT709, /**< BT.709 */ > (and automatic, but that's just BT.601 + BT.709) > > It's probably better to fall back to using BT.709 matrix for SMPTE 240M > (with a warning log) since BT.709 is closer to SMPTE 240M than BT.601 is. > No. This uses sRGB transfer. sRGB transfer is not close BT.709 OETF (or its BT.1886 EOTF) because sRGB is an EOTF in by itself. Please do not say it again. ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". > ___ 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 05/35] avdevice/dshow: set no-seek flags
Just resend them (without any -v2). ___ 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 05/35] avdevice/dshow: set no-seek flags
Actually I do not know how well will this work. Did you ever play any stream? Even if you play it without forcing seeking you are allowed to search forth due to how latency works. That problem with latency was only fixed in CMAF. ONE must to accelerate decoding forward in time to get low latency. Now hardware devices are different. But still, what about pause? What about seeking in the end which was BTW broken: see in https://patchwork.ffmpeg.org/project/ffmpeg/patch/20210604062818.2099-1-val.zapod...@gmail.com/ I mean, I agree this should be the default. ___ 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 24/35] avutil/opt: AVOptionRange gains is_set field.
Ah, yes, that is AVColorRange, sorry. :( Haha. ___ 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 24/35] avutil/opt: AVOptionRange gains is_set field.
Actually it is commonly understood all over the world that limited range is the default when not present. All video in the world except Dolby Vision profile 5 (if using IPTPQc2) is limited range. ___ 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 01/35] avdevice/dshow: implement option to use device video timestamps
Who knows what BS code "TODO figure out math. For now just drop them." means? Is PTS of the mentioned there can be even theoretically valid or not? ___ 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: 240M matrix is not the same as BT.601
Can you merge my mxfdec patch? Thank you. Maybe all my oldest patches too, except XYZ patch to libopenjpeg, that is WIP, since openjpeg did not even merge yet or did a release to support that wrapper option. Listen, it is commonly known that ffplay is broken, Carl agrees. MPV is not broken and is perfect according to reference calculator here. https://res18h39.netlify.app/color I did send you a sample in my "v1" patch (this is not v2, since v1 had wrong title, so v2 would be wrong thing to do, I just superseeded patch on patchwork). But for your comfort here it is again: https://trac.ffmpeg.org/attachment/ticket/9167/2.mp4 (also read #9167). Just *use* the sample above and ffplay it without any flags and ffplay with -vf scale=in_color_matrix=bt601,format=gbrp. I do not really care about ffplay, I care about Chromium (since I work on it) and now VLC. You can carefully read those two issues that use the sample above too. https://code.videolan.org/videolan/vlc/-/issues/25651 https://code.videolan.org/videolan/vlc/-/issues/25676 As you can see from those issues I know a lot about YCbCr and read the first documents from back when ITU-R was CCI(R). I even know that BT.709 was first defined in CCIR Rec. XA/11 1986-90f, a.k.a. IWP 11/6-2108 (Canada). That is not something you can fimd on the Internet, only in ITU-R archives (wikipedia is me, I wrote it there). So, please, stop with this. ___ 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: 240M matrix is not the same as BT.601
You are **very** wrong. This is YCbCr 101: 420 has all the same colors as 444 does. Just if one pixel is fixated the entagled pixels have less than all possible colors. This is also not corners issues, it is reproducable on one color all over the plane. Again, the workaround is to use ffplay -vf scale=in_color_matrix=bt601,format=gbrp. Why you cannot try it? It is not THAT hard. ___ 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: 240M matrix is not the same as BT.601
I cannot clarify it further, the issue is there on trac. ___ 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: fix input arguments for fate-unknown_layout-ac3
Do you know what command to use with http://fate-suite.ffmpeg.org/dolby_e/16-11.pcm? I used -ac 6, but I dunno everything else I used was not giving perfect sound (-f s16le -ac 6 was most important to at least get something playable). Sigh. Also I suppose sample rate will not be 48000 since it is PAL Dolby E. Thank you :) ___ 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] fftools/ffplay: 240M matrix is not the same as BT.601
Signed-off-by: Valerii Zapodovnikov
---
fftools/ffplay.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/fftools/ffplay.c b/fftools/ffplay.c
index 0be1d90bf9..53bd9362fa 100644
--- a/fftools/ffplay.c
+++ b/fftools/ffplay.c
@@ -963,12 +963,12 @@ static void set_sdl_yuv_conversion_mode(AVFrame *frame)
if (frame && (frame->format == AV_PIX_FMT_YUV420P || frame->format ==
AV_PIX_FMT_YUYV422 || frame->format == AV_PIX_FMT_UYVY422)) {
if (frame->color_range == AVCOL_RANGE_JPEG)
mode = SDL_YUV_CONVERSION_JPEG;
-else if (frame->colorspace == AVCOL_SPC_BT709)
+else if (frame->colorspace == AVCOL_SPC_BT709) /* FIXME: sometimes it
selects this even for BT.601 matrix, see issue 8862 */
mode = SDL_YUV_CONVERSION_BT709;
-else if (frame->colorspace == AVCOL_SPC_BT470BG || frame->colorspace
== AVCOL_SPC_SMPTE170M || frame->colorspace == AVCOL_SPC_SMPTE240M)
+else if (frame->colorspace == AVCOL_SPC_BT470BG || frame->colorspace
== AVCOL_SPC_SMPTE170M)
mode = SDL_YUV_CONVERSION_BT601;
}
-SDL_SetYUVConversionMode(mode);
+SDL_SetYUVConversionMode(mode); /* FIXME: no support for linear transfer */
#endif
}
--
2.30.2
___
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] fftools/ffprobe: 240M matrix is not the same as BT.601
So I am resending still with that comment and a typo fixed to "ffplay". I also found this: https://patchwork.ffmpeg.org/project/ffmpeg/patch/20180501194013.9552-8-one...@gmail.com/ It way be nice to apply that too, but then again my problem is not that. ___ 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] libavcodec: r12b decoder
In my case https://patchwork.ffmpeg.org/project/ffmpeg/patch/20210607063205.180031-1-val.zapod...@gmail.com/ v1 failed to apply due to https://github.com/FFmpeg/FFmpeg/commit/575e52272d42f4278c6620f1a999c41425db2094 I suppose in your case it is https://github.com/FFmpeg/FFmpeg/commit/8bcce5673a267ed371140bf3228ffb420ca2f69b which increased micro. P.S. Do not forget to make micro 100 when you increase minor version now. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v2] Revert "avformat/dashenc: Disable writing CODECS tag for HEVC streams"
This reverts commit d6d407d2d758b404af0ce6a8ff46bf164db020a1.
Hack not needed after a2b1dd0ce301450a47c972745a6b33c4c273aa5d.
Will fix #7480 and #8904.
This will include e.g. CODECS="hvc1.2.4.L123.B0" into m3u8.
Signed-off-by: Valerii Zapodovnikov
---
libavformat/dashenc.c | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c
index 810ab22416..8a626c15a4 100644
--- a/libavformat/dashenc.c
+++ b/libavformat/dashenc.c
@@ -1312,7 +1312,6 @@ static int write_manifest(AVFormatContext *s, int final)
AVStream *st = s->streams[i];
OutputStream *os = &c->streams[i];
char *agroup = NULL;
-char *codec_str_ptr = NULL;
int stream_bitrate = os->muxer_overhead;
if (os->bit_rate > 0)
stream_bitrate += os->bit_rate;
@@ -1331,13 +1330,10 @@ static int write_manifest(AVFormatContext *s, int final)
av_strlcat(codec_str, ",", sizeof(codec_str));
av_strlcat(codec_str, audio_codec_str, sizeof(codec_str));
}
-if (st->codecpar->codec_id != AV_CODEC_ID_HEVC) {
-codec_str_ptr = codec_str;
-}
get_hls_playlist_name(playlist_file, sizeof(playlist_file),
NULL, i);
ff_hls_write_stream_info(st, c->m3u8_out, stream_bitrate,
playlist_file, agroup,
- codec_str_ptr, NULL, NULL);
+ codec_str, NULL, NULL);
}
} else {
--
2.30.2
___
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 13/22] lavfi/scale_qsv: add more input / output pixel formats
So there are 4 formats two for le and 2 for be? Oogh. Do you know which one is used for dshow? ___ 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/5] avfilter/vf_ciescope: Handle black as very dark neutral gray
вс, 6 июн. 2021 г., 18:35 Michael Niedermayer : > On Sun, Jun 06, 2021 at 04:50:41PM +0300, Valerii Zapodovnikov wrote: > > I am sorry, what??? > > If that is intended as a review comment, please compose > a english sentance which represents what you are trying to convey. > That way others know what you mean. > > The goal of review is to improve code > > Anyway to elaborate on the rather trivial change > the code before the change has undefined behavior, that is a bug > in C per definition of what a bug is pretty much. > the change tried to replace the used value with one thats close > and not undefined. > we could skip black pixels or also use x=y=0 but later is > discontinous on all pathes with non negative color leading to black > so it felt a bit strange. But probably x=y=0 is a more strictly correct > choice, so ill change it to that. > > thx > > [...] > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > Many that live deserve death. And some that die deserve life. Can you give > it to them? Then do not be too eager to deal out death in judgement. For > even the very wise cannot see all ends. -- Gandalf > ___ > 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". > Nice, please change to that. And actually first link in google says https://stackoverflow.com/questions/42926763/ that it was defined in Annex F of ISO/IEC 9899 and gcc can do it, while clang cannot. I am not sure how one catches such NAN exceptions though. Moreover clang also wants that https://bugs.llvm.org/show_bug.cgi?id=19535#c13 and https://bugs.llvm.org/show_bug.cgi?id=17005, the last one even says and I quote: "The most visible issue caused by this is apparently that using -fsanitize=undefined on programs that make use of floating point division by 0.0 (which is perfectly legal udner IEEE floats) will print "runtime error: division by zero". (Also see: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=720935) It's also scary to think that your program might run slightly incorrectly in corner cases under clang, while it's correct under gcc (at least with -std=c99, gcc intentionally breaks floating point semantics with -std=gnu99)." Another bug in compiler, nothing to worry about IMHO. > ___ 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] ffmpeg: add -fpsmin to clamp output framerate
So did you fix your gmail account? Also, what happened to FATE? Broken? BTW, I just logged in my nvidia account through apple id and that email was marked as spam too, but because of my filter it was not send into spam! Cool :) ___ 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 13/22] lavfi/scale_qsv: add more input / output pixel formats
I hope it is the case since there was a problem with Intel P010 in Intel. #8055, comment 1, sample_YUV_intel10bits(P010LE).7z I still do not know what pixel format to force to decode that sample :) ___ 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/libopenjpeg: Interpret cinema profiles as XYZ
Actually it is not my patch (as should be obvious as From: is not me) and *NO* changes in API/ABI of openjpeg are happening with upsream patch. As for your ABI... There is only one correct way to manipulate openjpeg API, if you did that wrong, it is your problem. Standard thing: "unexpected that user code would allocate it with sizeof(opj_image_t)." I am just notifying your on this. Upstream is still not ready even, LOL. ___ 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/libopenjpeg: Interpret cinema profiles as XYZ
Did you even read the commit message? You need to apply a patch to openjpeg itself. Sigh. ___ 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/5] avfilter/vf_ciescope: Handle black as very dark neutral gray
I am sorry, what??? ___ 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] fftools/ffprobe: 240M matrix is not the same as BT.601
AVFrame->color_range? But even if I were using full range file (I do not) that would force BT.601 full range matrix (that is JPEG matrix) and I have the opposite here, BT.709 is forced. I suppose the problem can be checked with simple printf of frame->colorspace with that sample that uses BT.601. This one: https://trac.ffmpeg.org/attachment/ticket/9167/2.mp4 It should be wrong at that point. Or use breakpoint in debugger. :) Also, BTW, Nvidia drivers windows 10, what is matrix used for 4K YCbCr formats by default? Is it already BT.709? Because xvYCC can be both BT.601 and BT.709 (but it is only limited range, even if full is set by mistake, see latest "ANSI/CTA-861-H") and sYCC with selectable quantisation uses BT.601 even on 4K! But those are so called digital formats, they should be further forced. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] avcodec/libopenjpeg: Interpret cinema profiles as XYZ
From: Rémi Achard
Patch should be applied to decode XYZ samples with not native
decoder in ffmpeg (-c:v libopenjpeg, not -c:v jpeg2000). jpeg2000
works already.
Now, this is AFAIK a patch that should be applied after upstream's
patch: https://github.com/uclouvain/openjpeg/pull/1200
Please note that jpeg2000 XYZ is not bitperfect compared to openjpeg
see #4829#comment:3. Some pixels will be different, like in sYCC. I
consider both bugs. Also pixel_format can be forced by
"-pixel_format xyz12le".
---
libavcodec/libopenjpegdec.c | 44 +++--
1 file changed, 27 insertions(+), 17 deletions(-)
diff --git a/libavcodec/libopenjpegdec.c b/libavcodec/libopenjpegdec.c
index 8982d21be4..dff19586bb 100644
--- a/libavcodec/libopenjpegdec.c
+++ b/libavcodec/libopenjpegdec.c
@@ -71,6 +71,10 @@ static const enum AVPixelFormat libopenjpeg_gray_pix_fmts[]
= {
static const enum AVPixelFormat libopenjpeg_yuv_pix_fmts[] = {
YUV_PIXEL_FORMATS
};
+static const enum AVPixelFormat libopenjpeg_xyz_pix_fmts[] = {
+XYZ_PIXEL_FORMATS,
+YUV_PIXEL_FORMATS
+};
static const enum AVPixelFormat libopenjpeg_all_pix_fmts[] = {
RGB_PIXEL_FORMATS, GRAY_PIXEL_FORMATS, YUV_PIXEL_FORMATS, XYZ_PIXEL_FORMATS
};
@@ -196,23 +200,29 @@ static inline enum AVPixelFormat
libopenjpeg_guess_pix_fmt(const opj_image_t *im
const enum AVPixelFormat *possible_fmts = NULL;
int possible_fmts_nb = 0;
-switch (image->color_space) {
-case OPJ_CLRSPC_SRGB:
-possible_fmts= libopenjpeg_rgb_pix_fmts;
-possible_fmts_nb = FF_ARRAY_ELEMS(libopenjpeg_rgb_pix_fmts);
-break;
-case OPJ_CLRSPC_GRAY:
-possible_fmts= libopenjpeg_gray_pix_fmts;
-possible_fmts_nb = FF_ARRAY_ELEMS(libopenjpeg_gray_pix_fmts);
-break;
-case OPJ_CLRSPC_SYCC:
-possible_fmts= libopenjpeg_yuv_pix_fmts;
-possible_fmts_nb = FF_ARRAY_ELEMS(libopenjpeg_yuv_pix_fmts);
-break;
-default:
-possible_fmts= libopenjpeg_all_pix_fmts;
-possible_fmts_nb = FF_ARRAY_ELEMS(libopenjpeg_all_pix_fmts);
-break;
+if (image->rsiz == FF_PROFILE_JPEG2000_DCINEMA_2K ||
+image->rsiz == FF_PROFILE_JPEG2000_DCINEMA_4K) {
+possible_fmts = libopenjpeg_xyz_pix_fmts;
+possible_fmts_nb = FF_ARRAY_ELEMS(libopenjpeg_xyz_pix_fmts);
+} else {
+switch (image->color_space) {
+case OPJ_CLRSPC_SRGB:
+possible_fmts= libopenjpeg_rgb_pix_fmts;
+possible_fmts_nb = FF_ARRAY_ELEMS(libopenjpeg_rgb_pix_fmts);
+break;
+case OPJ_CLRSPC_GRAY:
+possible_fmts= libopenjpeg_gray_pix_fmts;
+possible_fmts_nb = FF_ARRAY_ELEMS(libopenjpeg_gray_pix_fmts);
+break;
+case OPJ_CLRSPC_SYCC:
+possible_fmts= libopenjpeg_yuv_pix_fmts;
+possible_fmts_nb = FF_ARRAY_ELEMS(libopenjpeg_yuv_pix_fmts);
+break;
+default:
+possible_fmts= libopenjpeg_all_pix_fmts;
+possible_fmts_nb = FF_ARRAY_ELEMS(libopenjpeg_all_pix_fmts);
+break;
+}
}
for (index = 0; index < possible_fmts_nb; ++index)
--
2.30.2
___
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 v3] lavc/aomdec: Allow RGB decoding
Yes, RGB is signalled by Identity matrix if and only if XYZ is not
in transfer. XYZ primaries are just normal primaries that can be
used for normal RGB, no problem, so I do not check for them.
No need to test for sRGB primaries (that is AVCOL_PRI_BT709), as
ffplay does not know what that is (is not color managed), but mpv
will do that automatically. This will also support other transfers
like DCI-P3 / DCI-D65 one, et cetera. See libvpxdec.c.
Also the default AV1 decoder is libdav1d, which is not affected.
For XYZ support someone should add correct pixel format in the code.
Signed-off-by: Valerii Zapodovnikov
---
libavcodec/libaomdec.c | 18 +++---
1 file changed, 15 insertions(+), 3 deletions(-)
diff --git a/libavcodec/libaomdec.c b/libavcodec/libaomdec.c
index 6e7324a832..156e644263 100644
--- a/libavcodec/libaomdec.c
+++ b/libavcodec/libaomdec.c
@@ -134,15 +134,27 @@ static int set_pix_fmt(AVCodecContext *avctx, struct
aom_image *img)
case AOM_IMG_FMT_I444:
case AOM_IMG_FMT_I44416:
if (img->bit_depth == 8) {
-avctx->pix_fmt = AV_PIX_FMT_YUV444P;
+if (avctx->colorspace == AVCOL_SPC_RGB && avctx->color_trc !=
AVCOL_TRC_SMPTE428) {
+avctx->pix_fmt = AV_PIX_FMT_GBRP;
+} else {
+avctx->pix_fmt = AV_PIX_FMT_YUV444P;
+}
avctx->profile = FF_PROFILE_AV1_HIGH;
return 0;
} else if (img->bit_depth == 10) {
-avctx->pix_fmt = AV_PIX_FMT_YUV444P10;
+if (avctx->colorspace == AVCOL_SPC_RGB && avctx->color_trc !=
AVCOL_TRC_SMPTE428) {
+avctx->pix_fmt = AV_PIX_FMT_GBRP10;
+} else {
+avctx->pix_fmt = AV_PIX_FMT_YUV444P10;
+}
avctx->profile = FF_PROFILE_AV1_HIGH;
return 0;
} else if (img->bit_depth == 12) {
-avctx->pix_fmt = AV_PIX_FMT_YUV444P12;
+if (avctx->colorspace == AVCOL_SPC_RGB && avctx->color_trc !=
AVCOL_TRC_SMPTE428) {
+avctx->pix_fmt = AV_PIX_FMT_GBRP12;
+} else {
+avctx->pix_fmt = AV_PIX_FMT_YUV444P12;
+}
avctx->profile = FF_PROFILE_AV1_PROFESSIONAL;
return 0;
} else {
--
2.30.2
___
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] lavc/aomdec: Allow RGB decoding
Forgot git commit -s, since it is more than 10 lines and not documentation changes it should be required. Sorry, also I will not add Co-authored-by: Carl <> since his patch was too flawed. Like really!? Oogh. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] avformat/mxfdec: fixed jp2k_rsiz and 170M matrix
Again. 240M matrix is different from BT.601! And 170M is the same
as BT.601. It is primaries that are the same in 240M and 170M, as
for jp2k_rsiz see page 17 of ST 422:2019. IT WAS THERE since 2006.
This wrong jp2k_rsiz is a copy-paste of header_open_partition_key.
---
libavformat/mxf.c| 2 +-
libavformat/mxfdec.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavformat/mxf.c b/libavformat/mxf.c
index 85a65f8718..7c355d789b 100644
--- a/libavformat/mxf.c
+++ b/libavformat/mxf.c
@@ -132,7 +132,7 @@ const MXFCodecUL ff_mxf_color_space_uls[] = {
{ {
0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x0D,0x04,0x01,0x01,0x01,0x02,0x05,0x00,0x00
}, 14, AVCOL_SPC_RGB }, /* GBR */
{ {
0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x0D,0x04,0x01,0x01,0x01,0x02,0x06,0x00,0x00
}, 14, AVCOL_SPC_BT2020_NCL }, /* ITU-R BT.2020 Non-Constant Luminance */
/* alternate mappings for encoding */
-{ {
0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x06,0x04,0x01,0x01,0x01,0x02,0x03,0x00,0x00
}, 14, AVCOL_SPC_SMPTE170M }, /* = AVCOL_SPC_SMPTE240M */
+{ {
0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x01,0x04,0x01,0x01,0x01,0x02,0x01,0x00,0x00
}, 14, AVCOL_SPC_SMPTE170M }, /* = AVCOL_SPC_BT470BG */
{ {
0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00
}, 0, AVCOL_SPC_UNSPECIFIED },
};
diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c
index 3bf480a3a6..9e92ef4175 100644
--- a/libavformat/mxfdec.c
+++ b/libavformat/mxfdec.c
@@ -330,7 +330,7 @@ static const uint8_t mxf_encrypted_triplet_key[]
= { 0x06,0x0e,0x2b,0x
static const uint8_t mxf_encrypted_essence_container[] = {
0x06,0x0e,0x2b,0x34,0x04,0x01,0x01,0x07,0x0d,0x01,0x03,0x01,0x02,0x0b,0x01,0x00
};
static const uint8_t mxf_sony_mpeg4_extradata[]= {
0x06,0x0e,0x2b,0x34,0x04,0x01,0x01,0x01,0x0e,0x06,0x06,0x02,0x02,0x01,0x00,0x00
};
static const uint8_t mxf_avid_project_name[] = {
0xa5,0xfb,0x7b,0x25,0xf6,0x15,0x94,0xb9,0x62,0xfc,0x37,0x17,0x49,0x2d,0x42,0xbf
};
-static const uint8_t mxf_jp2k_rsiz[] = {
0x06,0x0e,0x2b,0x34,0x02,0x05,0x01,0x01,0x0d,0x01,0x02,0x01,0x01,0x02,0x01,0x00
};
+static const uint8_t mxf_jp2k_rsiz[] = {
0x06,0x0e,0x2b,0x34,0x01,0x01,0x01,0x0a,0x04,0x01,0x06,0x03,0x01,0x00,0x00,0x00
};
static const uint8_t mxf_indirect_value_utf16le[] = {
0x4c,0x00,0x02,0x10,0x01,0x00,0x00,0x00,0x00,0x06,0x0e,0x2b,0x34,0x01,0x04,0x01,0x01
};
static const uint8_t mxf_indirect_value_utf16be[] = {
0x42,0x01,0x10,0x02,0x00,0x00,0x00,0x00,0x00,0x06,0x0e,0x2b,0x34,0x01,0x04,0x01,0x01
};
static const uint8_t mxf_apple_coll_max_cll[] = {
0x06,0x0e,0x2b,0x34,0x01,0x01,0x01,0x0e,0x0e,0x20,0x04,0x01,0x05,0x03,0x01,0x01
};
--
2.30.2
___
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] fftools/ffprobe: 240M matrix is not the same as BT.601
I am sorry, what? It converts to 420 always? Wow? But you are right. This is a problem that colors are wrong after YUV444 - > YUV420 -> RGB. It selects BT.709 matrix even if BT.601 matrix is requested, this can be fixed by "ffplay -vf scale=in_color_matrix=auto,format=gbrp" or just by using mpv. Maybe I need to further test VUI vs -movflags +write_colr vs what my samples use. ___ 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/mxfdec: fixed jp2k_rsiz and 240M matrix
Of course it is a PeRfEct copy paste, I should have mentioned that (and I asked Rémi to send the patch about RSIZ for XYZ, BTW). Also what this patch actually fixes is encoding 170M, not 240M. Will fix that too. Also should note that SMPTE ST 422:2019 is now free of charge. Yeah! ___ 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] lavfi/signature: fix always true expression
пн, 24 мая 2021 г., 4:00 Valerii Zapodovnikov :
> Otherwise since "==" has higher precedence, mode is never checked.
> ---
> libavfilter/signature_lookup.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavfilter/signature_lookup.c
> b/libavfilter/signature_lookup.c
> index 272c717c77..85e879d224 100644
> --- a/libavfilter/signature_lookup.c
> +++ b/libavfilter/signature_lookup.c
> @@ -491,7 +491,7 @@ static MatchingInfo
> evaluate_parameters(AVFilterContext *ctx, SignatureContext *
> meandist = (double) goodfcount / (double) distsum;
>
> if (meandist < minmeandist ||
> -status == STATUS_END_REACHED | STATUS_BEGIN_REACHED ||
> +status == (STATUS_END_REACHED | STATUS_BEGIN_REACHED) ||
> mode == MODE_FAST){
> minmeandist = meandist;
> /* bestcandidate in this iteration */
> --
> 2.30.2
>
Ping. And sorry for duplication. I did it, not patchwork or whatever :(
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] avformat/mxfdec: fixed jp2k_rsiz and 240M matrix
Again. 240M matrix is different from BT.601! And 170M is the same
as BT.601. It is primaries that are the same in 240M and 170M, as
for jp2k_rsiz see page 10 of S422M-2006. Yes, IT IS THERE.
---
libavformat/mxf.c| 2 +-
libavformat/mxfdec.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavformat/mxf.c b/libavformat/mxf.c
index 85a65f8718..7c355d789b 100644
--- a/libavformat/mxf.c
+++ b/libavformat/mxf.c
@@ -132,7 +132,7 @@ const MXFCodecUL ff_mxf_color_space_uls[] = {
{ {
0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x0D,0x04,0x01,0x01,0x01,0x02,0x05,0x00,0x00
}, 14, AVCOL_SPC_RGB }, /* GBR */
{ {
0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x0D,0x04,0x01,0x01,0x01,0x02,0x06,0x00,0x00
}, 14, AVCOL_SPC_BT2020_NCL }, /* ITU-R BT.2020 Non-Constant Luminance */
/* alternate mappings for encoding */
-{ {
0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x06,0x04,0x01,0x01,0x01,0x02,0x03,0x00,0x00
}, 14, AVCOL_SPC_SMPTE170M }, /* = AVCOL_SPC_SMPTE240M */
+{ {
0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x01,0x04,0x01,0x01,0x01,0x02,0x01,0x00,0x00
}, 14, AVCOL_SPC_SMPTE170M }, /* = AVCOL_SPC_BT470BG */
{ {
0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00
}, 0, AVCOL_SPC_UNSPECIFIED },
};
diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c
index 3bf480a3a6..9e92ef4175 100644
--- a/libavformat/mxfdec.c
+++ b/libavformat/mxfdec.c
@@ -330,7 +330,7 @@ static const uint8_t mxf_encrypted_triplet_key[]
= { 0x06,0x0e,0x2b,0x
static const uint8_t mxf_encrypted_essence_container[] = {
0x06,0x0e,0x2b,0x34,0x04,0x01,0x01,0x07,0x0d,0x01,0x03,0x01,0x02,0x0b,0x01,0x00
};
static const uint8_t mxf_sony_mpeg4_extradata[]= {
0x06,0x0e,0x2b,0x34,0x04,0x01,0x01,0x01,0x0e,0x06,0x06,0x02,0x02,0x01,0x00,0x00
};
static const uint8_t mxf_avid_project_name[] = {
0xa5,0xfb,0x7b,0x25,0xf6,0x15,0x94,0xb9,0x62,0xfc,0x37,0x17,0x49,0x2d,0x42,0xbf
};
-static const uint8_t mxf_jp2k_rsiz[] = {
0x06,0x0e,0x2b,0x34,0x02,0x05,0x01,0x01,0x0d,0x01,0x02,0x01,0x01,0x02,0x01,0x00
};
+static const uint8_t mxf_jp2k_rsiz[] = {
0x06,0x0e,0x2b,0x34,0x01,0x01,0x01,0x0a,0x04,0x01,0x06,0x03,0x01,0x00,0x00,0x00
};
static const uint8_t mxf_indirect_value_utf16le[] = {
0x4c,0x00,0x02,0x10,0x01,0x00,0x00,0x00,0x00,0x06,0x0e,0x2b,0x34,0x01,0x04,0x01,0x01
};
static const uint8_t mxf_indirect_value_utf16be[] = {
0x42,0x01,0x10,0x02,0x00,0x00,0x00,0x00,0x00,0x06,0x0e,0x2b,0x34,0x01,0x04,0x01,0x01
};
static const uint8_t mxf_apple_coll_max_cll[] = {
0x06,0x0e,0x2b,0x34,0x01,0x01,0x01,0x0e,0x0e,0x20,0x04,0x01,0x05,0x03,0x01,0x01
};
--
2.30.2
___
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/hls Implement support for using AVSEEK_FLAG_BACKWARD when seeking
BTW, what about #7359? ___ 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] libavcodec: r12b decoder
That did work, cool. https://patchwork.ffmpeg.org/project/ffmpeg/patch/capucmebbw-rkt3mw5berkg3cqa+-akryfahclfc36mh2ybn...@mail.gmail.com/ BTW, will have to look into patchwork's patchwork (D:)) whether they fixed .patch extensions. Apparently not. Also everything in "Re:" cannot contain a patch. Ha. ___ 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] Revert "avformat/dashenc: Disable writing CODECS tag for HEVC streams"
This reverts commit d6d407d2d758b404af0ce6a8ff46bf164db020a1.
Hack not needed after a2b1dd0ce301450a47c972745a6b33c4c273aa5d.
Will fix #7480 and #8904.
This will include e.g. CODECS="hvc1.2.4.L123.B0" into m3u8.
Signed-off-by: Valerii Zapodovnikov
---
libavformat/dashenc.c | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c
index ebbdfd627c..b0fb408f0d 100644
--- a/libavformat/dashenc.c
+++ b/libavformat/dashenc.c
@@ -1309,7 +1309,6 @@ static int write_manifest(AVFormatContext *s, int final)
AVStream *st = s->streams[i];
OutputStream *os = &c->streams[i];
char *agroup = NULL;
-char *codec_str_ptr = NULL;
int stream_bitrate = os->muxer_overhead;
if (os->bit_rate > 0)
stream_bitrate += os->bit_rate;
@@ -1328,13 +1327,10 @@ static int write_manifest(AVFormatContext *s, int final)
av_strlcat(codec_str, ",", sizeof(codec_str));
av_strlcat(codec_str, audio_codec_str, sizeof(codec_str));
}
-if (st->codecpar->codec_id != AV_CODEC_ID_HEVC) {
-codec_str_ptr = codec_str;
-}
get_hls_playlist_name(playlist_file, sizeof(playlist_file), NULL,
i);
ff_hls_write_stream_info(st, c->m3u8_out, stream_bitrate,
playlist_file, agroup,
- codec_str_ptr, NULL, NULL);
+ codec_str, NULL, NULL);
}
dashenc_io_close(s, &c->m3u8_out, temp_filename);
if (use_rename)
--
2.30.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] avformat/mov.c: trun atom sample should be logged from 0
Just like for stss atom. Suggested-By: Nick Ryan --- libavformat/mov.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libavformat/mov.c b/libavformat/mov.c index c088c9f515..1be2783556 100644 --- a/libavformat/mov.c +++ b/libavformat/mov.c @@ -4936,11 +4936,11 @@ static int mov_read_trun(MOVContext *c, AVIOContext *pb, MOVAtom atom) sc->ctts_data[index_entry_pos].count = 1; sc->ctts_data[index_entry_pos].duration = ctts_duration; -index_entry_pos++; av_log(c->fc, AV_LOG_TRACE, "AVIndex stream %d, sample %d, offset %"PRIx64", dts %"PRId64", " "size %u, distance %d, keyframe %d\n", st->index, index_entry_pos, offset, dts, sample_size, distance, keyframe); +index_entry_pos++; distance++; dts += sample_duration; offset += sample_size; -- 2.30.2 ___ 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] libavcodec: r12b decoder
Nope, still is not seen. Try to send .txt in new thread. 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] avformat/nut: add support for P010 pixel format
GEN=1 is nice, but why diff is no longer working on patchwork itself? See: https://patchwork.ffmpeg.org/check/18368/ ___ 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/nut: add support for P010 pixel format
Okay, I will send a patch to just raw.c to check it out, if it will not work I will send against http://lists.mplayerhq.hu/pipermail/nut-devel/2020-December/thread.html Again, who can do FATE hashes for me? Please? ___ 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/ccaption_dec: Make real-time latency configurable v2
Sure, please resend and change status on your old patch as superseeded on patchwork. Sigh. As for maintainer, LGTM from me (interesting, is just saying those 4 latters enough to get patchwork flag of it?). So if you can push while not being the mainteiner, please do it, the coding acceptions here are like really slow, 3 days ago my pull request on github was merged in 3 hours by Microsoft! And anyway, ccextractor is what is more used out there, is not it. And Timo does not want to add cc to cuviddec!! Oogh. See: https://patchwork.ffmpeg.org/project/ffmpeg/patch/20210413143510.93256-1-dhanishvija...@gmail.com/ ___ 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/hls Implement support for using AVSEEK_FLAG_BACKWARD when seeking
You forgot to mention #6850. Also you patch was not seen by patchwork. Please use "git send-email -v2 -1" to send v2 patch. 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] avcodec/ccaption_dec: Make real-time latency configurable v2
v2 is done by "git send-email -v2 -1" not what you did here. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v2] lavc/aomdec: Allow RGB decoding
Yes, RGB is signalled by Identity matrix if and only if XYZ is not
in transfer. XYZ primaires are just normal primaries that can be
used for normal RGB, no problem, so I do not check for them.
No need to test for sRGB primaries (that is AVCOL_PRI_BT709), as
ffplay does not know what that is (is not color managed), but mpv
will do that automatically. This will also support other transfers
like DCI-P3 / DCI-D65 one, et cetera. See libvpxdec.c.
Also the default AV1 decoder is libdav1d, which is not affected.
For XYZ support someone should add correct pixel format in the code.
---
libavcodec/libaomdec.c | 18 +++---
1 file changed, 15 insertions(+), 3 deletions(-)
diff --git a/libavcodec/libaomdec.c b/libavcodec/libaomdec.c
index 6e7324a832..156e644263 100644
--- a/libavcodec/libaomdec.c
+++ b/libavcodec/libaomdec.c
@@ -134,15 +134,27 @@ static int set_pix_fmt(AVCodecContext *avctx, struct
aom_image *img)
case AOM_IMG_FMT_I444:
case AOM_IMG_FMT_I44416:
if (img->bit_depth == 8) {
-avctx->pix_fmt = AV_PIX_FMT_YUV444P;
+if (avctx->colorspace == AVCOL_SPC_RGB && avctx->color_trc !=
AVCOL_TRC_SMPTE428) {
+avctx->pix_fmt = AV_PIX_FMT_GBRP;
+} else {
+avctx->pix_fmt = AV_PIX_FMT_YUV444P;
+}
avctx->profile = FF_PROFILE_AV1_HIGH;
return 0;
} else if (img->bit_depth == 10) {
-avctx->pix_fmt = AV_PIX_FMT_YUV444P10;
+if (avctx->colorspace == AVCOL_SPC_RGB && avctx->color_trc !=
AVCOL_TRC_SMPTE428) {
+avctx->pix_fmt = AV_PIX_FMT_GBRP10;
+} else {
+avctx->pix_fmt = AV_PIX_FMT_YUV444P10;
+}
avctx->profile = FF_PROFILE_AV1_HIGH;
return 0;
} else if (img->bit_depth == 12) {
-avctx->pix_fmt = AV_PIX_FMT_YUV444P12;
+if (avctx->colorspace == AVCOL_SPC_RGB && avctx->color_trc !=
AVCOL_TRC_SMPTE428) {
+avctx->pix_fmt = AV_PIX_FMT_GBRP12;
+} else {
+avctx->pix_fmt = AV_PIX_FMT_YUV444P12;
+}
avctx->profile = FF_PROFILE_AV1_PROFESSIONAL;
return 0;
} else {
--
2.30.2
___
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] avfilter/vf_hqdn3d: fix left shift of negative numbers
пн, 24 мая 2021 г., 6:42 Valerii Zapodovnikov : > --- > libavfilter/vf_hqdn3d.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/libavfilter/vf_hqdn3d.c b/libavfilter/vf_hqdn3d.c > index 8d71ae316d..bd3eb2d01c 100644 > --- a/libavfilter/vf_hqdn3d.c > +++ b/libavfilter/vf_hqdn3d.c > @@ -179,7 +179,7 @@ static void precalc_coefs(double dist25, int depth, > int16_t *ct) > > gamma = log(0.25) / log(1.0 - FFMIN(dist25,252.0)/255.0 - 0.1); > > -for (i = -256< +for (i = -(256< double f = ((i<<(9-LUT_BITS)) + (1<<(8-LUT_BITS)) - 1) / 512.0; > // midpoint of the bin > simil = FFMAX(0, 1.0 - fabs(f) / 255.0); > C = pow(simil, gamma) * 256.0 * f; > -- > 2.30.2 > Ping. > ___ 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: Pass the HDR10+ metadata to the packet side data in VP9 encoder
Yeah, 0 to 3, but this is 4. We are counting from 0, not from 1. So that would be some kind of fifth profile. ___ 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] avdevice/avdevice: Deprecate AVDevice Capabilities API
You may want to wait for at least some review and then of course, Andreas, for example, sometimes sends 200 patch series. https://patchwork.ffmpeg.org/project/ffmpeg/patch/20201203003628.778278-6-andreas.rheinha...@gmail.com/ ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v2] avformat/avio: fixed AVSEEK_FORCE and documentation
Always true expression: we would have returned on line 265,
if whence were SEEK_END we would've already returned.
Because of short circuiting force will never be checked.
Was broken since 7a6fe01f99cb95797ba59134f44bb1a5e792.
That is 11 years! Also fixed other commit that did confuse
ORing / passing: 41ed7ab45fc693f7d7fc35664c0233f4c32d69bb.
---
libavformat/avio.h| 4 ++--
libavformat/aviobuf.c | 3 +--
2 files changed, 3 insertions(+), 4 deletions(-)
diff --git a/libavformat/avio.h b/libavformat/avio.h
index 0b35409787..83e2a71b67 100644
--- a/libavformat/avio.h
+++ b/libavformat/avio.h
@@ -505,14 +505,14 @@ int avio_put_str16be(AVIOContext *s, const char *str);
void avio_write_marker(AVIOContext *s, int64_t time, enum AVIODataMarkerType
type);
/**
- * ORing this as the "whence" parameter to a seek function causes it to
+ * Passing this as the "whence" parameter to a seek function causes it to
* return the filesize without seeking anywhere. Supporting this is optional.
* If it is not supported then the seek function will return <0.
*/
#define AVSEEK_SIZE 0x1
/**
- * Passing this flag as the "whence" parameter to a seek function causes it to
+ * OR'ing this flag into the "whence" parameter to a seek function causes it to
* seek by any means (like reopening and linear reading) or other normally
unreasonable
* means that can be extremely slow.
* This may be ignored by the seek code.
diff --git a/libavformat/aviobuf.c b/libavformat/aviobuf.c
index ddfa4ecbf1..d748cda397 100644
--- a/libavformat/aviobuf.c
+++ b/libavformat/aviobuf.c
@@ -286,8 +286,7 @@ int64_t avio_seek(AVIOContext *s, int64_t offset, int
whence)
} else if ((!(s->seekable & AVIO_SEEKABLE_NORMAL) ||
offset1 <= buffer_size + short_seek) &&
!s->write_flag && offset1 >= 0 &&
- (!s->direct || !s->seek) &&
- (whence != SEEK_END || force)) {
+ (!s->direct || !s->seek) || force) {
while(s->pos < offset && !s->eof_reached)
fill_buffer(s);
if (s->eof_reached)
--
2.30.2
___
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] ffmpeg: add -fpsmin to clamp output framerate
It is not going to work. His email is marked as spam here in gmail for android, so it looks like it is globally banned in google and because you clever guys use gmail for patchwork, i.e. ffmpegpatchwo...@gmail.com but you did not set to send all spam into main folder, like I always do, see https://webapps.stackexchange.com/questions/1307/ it is not recognising it. I personally use this: instead of "has the words" method that was banned by some nut in google (I still did not found out who did that) I use the opposite with some crazy thing like faewfaefagvfdvfaefeffdvcvfea. And it will send all "spam" to main folder. Yeah. ___ 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] libavcodec: r12b decoder
You patch did not apply on patchwork and thus did not make fate tests. Please use .txt extension on the patch (BTW, what a joke) or use git send-email. It is also very funny that gmail for android recognises patch as video. Wht? ___ 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/nut: add support for P010 pixel format
The bigger problem are FATE hashes. I am not able to fill them here. As to send patches against another repo, I can do that, no problem with --subject-prefix="PATCH nut". Also, I do not see a problem with the spec, the spec says that it has priority, not the code. I am not doing this patch for nut.c, but for dshow to support HDR, but HDR signalling is PQ transfer and other patches implement reading that. I still do not know whether endianness is swapped in dshow and what sample location means for P010, BTW. ___ 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: Pass the HDR10+ metadata to the packet side data in VP9 encoder
HDR10+ test bitstream https://www.webmproject.org/vp9/levels/ BTW, who knows what is Profile 4 VP9 (i.e. VP9.4)? https://stackoverflow.com/questions/61413665 ___ 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/nut: add support for P010 pixel format
I don't really care about your nut container, FATE just complains that something in raw.c is not in nut.c. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v2] avcodec/dpxenc: stop hardcoding color trc/primaries
Updated FATE hashes and added gamma 2.8. Also please note that FATE
samples are useless. I also fixed gamma 2.2 to System M.
Also this does not do YCbCr stuff, so no matrices are here.
Fixes more or less #6023, except for printing density stuff.
Co-authored-by: Paul B Mahol
---
libavcodec/dpxenc.c | 38 +--
tests/ref/lavf/dpx| 2 +-
tests/ref/lavf/gbrp10le.dpx | 2 +-
tests/ref/lavf/gbrp12le.dpx | 2 +-
tests/ref/lavf/rgb48le.dpx| 2 +-
tests/ref/lavf/rgb48le_10.dpx | 2 +-
tests/ref/lavf/rgba64le.dpx | 2 +-
7 files changed, 42 insertions(+), 8 deletions(-)
diff --git a/libavcodec/dpxenc.c b/libavcodec/dpxenc.c
index fa8b7d5ddc..90a47dc21e 100644
--- a/libavcodec/dpxenc.c
+++ b/libavcodec/dpxenc.c
@@ -174,6 +174,40 @@ static void encode_gbrp12(AVCodecContext *avctx, const
AVFrame *pic, uint8_t *ds
}
}
+static int get_dpx_pri(int color_pri)
+{
+switch (color_pri) {
+case AVCOL_PRI_BT709:
+return 6;
+case AVCOL_PRI_SMPTE240M:
+case AVCOL_PRI_SMPTE170M:
+return 9;
+case AVCOL_PRI_BT470BG:
+return 10;
+default:
+return 0;
+}
+}
+
+static int get_dpx_trc(int color_trc)
+{
+switch (color_trc) {
+case AVCOL_TRC_LINEAR:
+return 2;
+case AVCOL_TRC_BT709:
+return 6;
+case AVCOL_TRC_SMPTE240M:
+case AVCOL_TRC_SMPTE170M:
+return 9;
+case AVCOL_TRC_GAMMA22:
+return 8;
+case AVCOL_TRC_GAMMA28:
+return 7;
+default:
+return 0;
+}
+}
+
static int encode_frame(AVCodecContext *avctx, AVPacket *pkt,
const AVFrame *frame, int *got_packet)
{
@@ -219,8 +253,8 @@ static int encode_frame(AVCodecContext *avctx, AVPacket
*pkt,
write32(buf + 772, avctx->width);
write32(buf + 776, avctx->height);
buf[800] = s->descriptor;
-buf[801] = 2; /* linear transfer */
-buf[802] = 2; /* linear colorimetric */
+buf[801] = get_dpx_trc(avctx->color_trc);
+buf[802] = get_dpx_pri(avctx->color_primaries);
buf[803] = s->bits_per_component;
write16(buf + 804, (s->bits_per_component == 10 || s->bits_per_component
== 12) ?
1 : 0); /* packing method */
diff --git a/tests/ref/lavf/dpx b/tests/ref/lavf/dpx
index 68fe25afcd..39e513430a 100644
--- a/tests/ref/lavf/dpx
+++ b/tests/ref/lavf/dpx
@@ -1,3 +1,3 @@
-4c8880d5835ffb5fe37c1ed8c8d404de *tests/data/images/dpx/02.dpx
+233e219cbfa61e0b77f8e4fad05b2404 *tests/data/images/dpx/02.dpx
tests/data/images/dpx/%02d.dpx CRC=0x6da01946
305792 tests/data/images/dpx/02.dpx
diff --git a/tests/ref/lavf/gbrp10le.dpx b/tests/ref/lavf/gbrp10le.dpx
index b33da34e20..16ac9ebc66 100644
--- a/tests/ref/lavf/gbrp10le.dpx
+++ b/tests/ref/lavf/gbrp10le.dpx
@@ -1,3 +1,3 @@
-7ca935d5d5e00c54acbc85565d3039b6
*tests/data/images/gbrp10le.dpx/02.gbrp10le.dpx
+69b9da05fa73a4495ea04ce5f45b51d6
*tests/data/images/gbrp10le.dpx/02.gbrp10le.dpx
tests/data/images/gbrp10le.dpx/%02d.gbrp10le.dpx CRC=0xe6663fba
407168 tests/data/images/gbrp10le.dpx/02.gbrp10le.dpx
diff --git a/tests/ref/lavf/gbrp12le.dpx b/tests/ref/lavf/gbrp12le.dpx
index e2e794ecc6..8b9dae4fbc 100644
--- a/tests/ref/lavf/gbrp12le.dpx
+++ b/tests/ref/lavf/gbrp12le.dpx
@@ -1,3 +1,3 @@
-a4cfea1797c928f2eff73573e559675d
*tests/data/images/gbrp12le.dpx/02.gbrp12le.dpx
+056a0852dcd8e4d8727114df4a247dd4
*tests/data/images/gbrp12le.dpx/02.gbrp12le.dpx
tests/data/images/gbrp12le.dpx/%02d.gbrp12le.dpx CRC=0x1c755633
609920 tests/data/images/gbrp12le.dpx/02.gbrp12le.dpx
diff --git a/tests/ref/lavf/rgb48le.dpx b/tests/ref/lavf/rgb48le.dpx
index 073153898a..803bb0f5e6 100644
--- a/tests/ref/lavf/rgb48le.dpx
+++ b/tests/ref/lavf/rgb48le.dpx
@@ -1,3 +1,3 @@
-075963c3c08978b6a20555ba09161434 *tests/data/images/rgb48le.dpx/02.rgb48le.dpx
+6e7d757279eaa914a92be107f8f01077 *tests/data/images/rgb48le.dpx/02.rgb48le.dpx
tests/data/images/rgb48le.dpx/%02d.rgb48le.dpx CRC=0xe5b9c023
609920 tests/data/images/rgb48le.dpx/02.rgb48le.dpx
diff --git a/tests/ref/lavf/rgb48le_10.dpx b/tests/ref/lavf/rgb48le_10.dpx
index ce36e5079f..dfeb059787 100644
--- a/tests/ref/lavf/rgb48le_10.dpx
+++ b/tests/ref/lavf/rgb48le_10.dpx
@@ -1,3 +1,3 @@
-b9f22728f8ff393bf30cf6cbd624fa95
*tests/data/images/rgb48le_10.dpx/02.rgb48le_10.dpx
+097c4ff8138d76bffa51c1e8c36ea90f
*tests/data/images/rgb48le_10.dpx/02.rgb48le_10.dpx
tests/data/images/rgb48le_10.dpx/%02d.rgb48le_10.dpx CRC=0xf38d5830
407168 tests/data/images/rgb48le_10.dpx/02.rgb48le_10.dpx
diff --git a/tests/ref/lavf/rgba64le.dpx b/tests/ref/lavf/rgba64le.dpx
index b4092c9fd8..82771c41bd 100644
--- a/tests/ref/lavf/rgba64le.dpx
+++ b/tests/ref/lavf/rgba64le.dpx
@@ -1,3 +1,3 @@
-545603630f30dec2768c8ae8d12eb8ea
*tests/data/images/rgba64le.dpx/02.rgba64le.dpx
+51ccad3d05c1cef9db958adf01c9b55f
*tests/data/images/rgba64le.dpx/02.rgba64le.dpx
tests/data/images/rgba64le.dpx/%02d.rgba64le.dpx CRC=0xe72ce131
812672 tests/data/images/rgba64le
[FFmpeg-devel] [PATCH] avformat/nut: add support for P010 pixel format
This is used for dshow, though may be swapped endianness there.
Fixes #8454. fate-pixdesc-p010le and be will have to be updated.
---
libavcodec/raw.c | 3 +++
libavformat/nut.c | 3 +++
2 files changed, 6 insertions(+)
diff --git a/libavcodec/raw.c b/libavcodec/raw.c
index 079d5c5d10..7efc0156ca 100644
--- a/libavcodec/raw.c
+++ b/libavcodec/raw.c
@@ -224,6 +224,9 @@ const PixelFormatTag ff_raw_pix_fmt_tags[] = {
{ AV_PIX_FMT_BAYER_GRBG16LE, MKTAG(0xBA, 'G', 'R', 16 ) },
{ AV_PIX_FMT_BAYER_GRBG16BE, MKTAG(16, 'R', 'G', 0xBA) },
+{ AV_PIX_FMT_P010LE, MKTAG('P', '0', '1', '0') },
+{ AV_PIX_FMT_P010BE, MKTAG('0', '1', '0', 'P') },
+
/* quicktime */
{ AV_PIX_FMT_YUV420P, MKTAG('R', '4', '2', '0') }, /* Radius DV YUV PAL */
{ AV_PIX_FMT_YUV411P, MKTAG('R', '4', '1', '1') }, /* Radius DV YUV NTSC */
diff --git a/libavformat/nut.c b/libavformat/nut.c
index 47ed152529..c69a9ab6ad 100644
--- a/libavformat/nut.c
+++ b/libavformat/nut.c
@@ -205,6 +205,9 @@ const AVCodecTag ff_nut_video_tags[] = {
{ AV_CODEC_ID_RAWVIDEO, MKTAG(0xBA, 'G', 'R', 16 ) },
{ AV_CODEC_ID_RAWVIDEO, MKTAG(16, 'R', 'G', 0xBA) },
+{ AV_CODEC_ID_RAWVIDEO, MKTAG('P', '0', '1', '0') },
+{ AV_CODEC_ID_RAWVIDEO, MKTAG('0', '1', '0', 'P') },
+
{ AV_CODEC_ID_NONE, 0 }
};
--
2.30.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] avcodec/audiotoolboxdec: Fix decoding 24 Bit ALAC
"avctx->bits_per_raw_sample" always returns 0.
Tested with 24 Bit ALAC. The result is bit-perfect.
Fix #7287.
Co-authored-by: Davis
---
libavcodec/audiotoolboxdec.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/audiotoolboxdec.c b/libavcodec/audiotoolboxdec.c
index cbd381ef12..c7e1760645 100644
--- a/libavcodec/audiotoolboxdec.c
+++ b/libavcodec/audiotoolboxdec.c
@@ -303,7 +303,7 @@ static av_cold int ffat_create_decoder(AVCodecContext
*avctx,
OSStatus status;
int i;
-enum AVSampleFormat sample_fmt = (avctx->bits_per_raw_sample == 32) ?
+enum AVSampleFormat sample_fmt = (avctx->bits_per_coded_sample > 16) ?
AV_SAMPLE_FMT_S32 : AV_SAMPLE_FMT_S16;
AudioStreamBasicDescription in_format = {
--
2.30.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] avcodec/audiotoolboxdec: Fix decoding 24 Bit ALAC "avctx->bits_per_raw_sample" always returns 0. Tested with 24 Bit ALAC. The result is bit-perfect. Fix #7287.
Co-authored-by: Davis
---
libavcodec/audiotoolboxdec.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/audiotoolboxdec.c b/libavcodec/audiotoolboxdec.c
index cbd381ef12..c7e1760645 100644
--- a/libavcodec/audiotoolboxdec.c
+++ b/libavcodec/audiotoolboxdec.c
@@ -303,7 +303,7 @@ static av_cold int ffat_create_decoder(AVCodecContext
*avctx,
OSStatus status;
int i;
-enum AVSampleFormat sample_fmt = (avctx->bits_per_raw_sample == 32) ?
+enum AVSampleFormat sample_fmt = (avctx->bits_per_coded_sample > 16) ?
AV_SAMPLE_FMT_S32 : AV_SAMPLE_FMT_S16;
AudioStreamBasicDescription in_format = {
--
2.30.2
___
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 v3] pixfmt: fixed wrong fix of comment
This mostly reverts 785bfb1d7bb8de567c3aac1d9cc369b55ac9fb7b.
But I also added some clarifications so that nobody mixes primaries
with matrix again. SMPTE 240 and 170 primaires are the same, while
matrix coeff. are different, because 240 is derived from 170's new
primaries and white point while 170 uses BT.601 derived from BT.470
System M (yes, with Illuminant C) a.k.a. NTSC 1953. Some nits too.
---
libavutil/pixfmt.h | 36 ++--
1 file changed, 18 insertions(+), 18 deletions(-)
diff --git a/libavutil/pixfmt.h b/libavutil/pixfmt.h
index 30591133a4..5814f3f3da 100644
--- a/libavutil/pixfmt.h
+++ b/libavutil/pixfmt.h
@@ -443,32 +443,32 @@ enum AVPixelFormat {
/**
* Chromaticity coordinates of the source primaries.
- * These values match the ones defined by ISO/IEC 23001-8_2013 § 7.1.
+ * These values match the ones defined by ISO/IEC 23091-2_2019 subclause 8.1
and ITU-T H.273.
*/
enum AVColorPrimaries {
AVCOL_PRI_RESERVED0 = 0,
-AVCOL_PRI_BT709 = 1, ///< also ITU-R BT1361 / IEC 61966-2-4 / SMPTE
RP177 Annex B
+AVCOL_PRI_BT709 = 1, ///< also ITU-R BT1361 / IEC 61966-2-4 / SMPTE
RP 177 Annex B
AVCOL_PRI_UNSPECIFIED = 2,
AVCOL_PRI_RESERVED= 3,
AVCOL_PRI_BT470M = 4, ///< also FCC Title 47 Code of Federal
Regulations 73.682 (a)(20)
AVCOL_PRI_BT470BG = 5, ///< also ITU-R BT601-6 625 / ITU-R BT1358 625
/ ITU-R BT1700 625 PAL & SECAM
AVCOL_PRI_SMPTE170M = 6, ///< also ITU-R BT601-6 525 / ITU-R BT1358 525
/ ITU-R BT1700 NTSC
-AVCOL_PRI_SMPTE240M = 7, ///< functionally identical to above
+AVCOL_PRI_SMPTE240M = 7, ///< identical to above, also called "SMPTE C"
even though it uses D65
AVCOL_PRI_FILM= 8, ///< colour filters using Illuminant C
AVCOL_PRI_BT2020 = 9, ///< ITU-R BT2020
AVCOL_PRI_SMPTE428= 10, ///< SMPTE ST 428-1 (CIE 1931 XYZ)
AVCOL_PRI_SMPTEST428_1 = AVCOL_PRI_SMPTE428,
AVCOL_PRI_SMPTE431= 11, ///< SMPTE ST 431-2 (2011) / DCI P3
AVCOL_PRI_SMPTE432= 12, ///< SMPTE ST 432-1 (2010) / P3 D65 / Display
P3
-AVCOL_PRI_EBU3213 = 22, ///< EBU Tech. 3213-E / JEDEC P22 phosphors
+AVCOL_PRI_EBU3213 = 22, ///< EBU Tech. 3213-E (nothing there) / one of
JEDEC P22 group phosphors
AVCOL_PRI_JEDEC_P22 = AVCOL_PRI_EBU3213,
AVCOL_PRI_NB///< Not part of ABI
};
/**
* Color Transfer Characteristic.
- * These values match the ones defined by ISO/IEC 23001-8_2013 § 7.2.
+ * These values match the ones defined by ISO/IEC 23091-2_2019 subclause 8.2.
*/
enum AVColorTransferCharacteristic {
AVCOL_TRC_RESERVED0= 0,
@@ -497,18 +497,18 @@ enum AVColorTransferCharacteristic {
/**
* YUV colorspace type.
- * These values match the ones defined by ISO/IEC 23001-8_2013 § 7.3.
+ * These values match the ones defined by ISO/IEC 23091-2_2019 subclause 8.3.
*/
enum AVColorSpace {
-AVCOL_SPC_RGB = 0, ///< order of coefficients is actually GBR,
also IEC 61966-2-1 (sRGB)
-AVCOL_SPC_BT709 = 1, ///< also ITU-R BT1361 / IEC 61966-2-4
xvYCC709 / SMPTE RP177 Annex B
+AVCOL_SPC_RGB = 0, ///< order of coefficients is actually GBR,
also IEC 61966-2-1 (sRGB), YZX and ST 428-1
+AVCOL_SPC_BT709 = 1, ///< also ITU-R BT1361 / IEC 61966-2-4
xvYCC709 / derived in SMPTE RP 177 Annex B
AVCOL_SPC_UNSPECIFIED = 2,
-AVCOL_SPC_RESERVED= 3,
+AVCOL_SPC_RESERVED= 3, ///< reserved for future use by ITU-T and
ISO/IEC just like 15-255 are
AVCOL_SPC_FCC = 4, ///< FCC Title 47 Code of Federal Regulations
73.682 (a)(20)
AVCOL_SPC_BT470BG = 5, ///< also ITU-R BT601-6 625 / ITU-R BT1358 625
/ ITU-R BT1700 625 PAL & SECAM / IEC 61966-2-4 xvYCC601
-AVCOL_SPC_SMPTE170M = 6, ///< also ITU-R BT601-6 525 / ITU-R BT1358 525
/ ITU-R BT1700 NTSC
-AVCOL_SPC_SMPTE240M = 7, ///< functionally identical to above
-AVCOL_SPC_YCGCO = 8, ///< Used by Dirac / VC-2 and H.264 FRext, see
ITU-T SG16
+AVCOL_SPC_SMPTE170M = 6, ///< also ITU-R BT601-6 525 / ITU-R BT1358 525
/ ITU-R BT1700 NTSC / functionally identical to above
+AVCOL_SPC_SMPTE240M = 7, ///< derived from 170M primaries and D65 white
point, 170M is derived from BT470 System M's primaries
+AVCOL_SPC_YCGCO = 8, ///< used by Dirac / VC-2 and H.264 FRext, see
ITU-T SG16
AVCOL_SPC_YCOCG = AVCOL_SPC_YCGCO,
AVCOL_SPC_BT2020_NCL = 9, ///< ITU-R BT2020 non-constant luminance system
AVCOL_SPC_BT2020_CL = 10, ///< ITU-R BT2020 constant luminance system
@@ -530,9 +530,9 @@ enum AVColorSpace {
* recommended, as it also defines the full range representation.
*
* Common definitions:
- * - For RGB and luminance planes such as Y in YCbCr and I in ICtCp,
+ * - For RGB and luma planes such as Y in YCbCr and I in ICtCp,
* 'E' is the original value in range of 0.0 to 1.0.
- * - For chrominance planes suc
[FFmpeg-devel] [PATCH v2] pixfmt: fixed wrong fix of comment
This mostly reverts 785bfb1d7bb8de567c3aac1d9cc369b55ac9fb7b.
But I also added some clarifications so that nobody mixes primaries
with matrix again. SMPTE 240 and 170 primaires are the same, while
matrix coeff. are different, because 240 is derived from 170's new
primaries and white point while 170 uses BT.601 derived from BT.470
System M (yes, with Illuminant C) a.k.a. NTSC 1953. Some nits too.
---
libavutil/pixfmt.h | 32
1 file changed, 16 insertions(+), 16 deletions(-)
diff --git a/libavutil/pixfmt.h b/libavutil/pixfmt.h
index 30591133a4..75018418a9 100644
--- a/libavutil/pixfmt.h
+++ b/libavutil/pixfmt.h
@@ -443,25 +443,25 @@ enum AVPixelFormat {
/**
* Chromaticity coordinates of the source primaries.
- * These values match the ones defined by ISO/IEC 23001-8_2013 § 7.1.
+ * These values match the ones defined by ISO/IEC 23001-8_2013 § 7.1 and
ITU-T H.273.
*/
enum AVColorPrimaries {
AVCOL_PRI_RESERVED0 = 0,
-AVCOL_PRI_BT709 = 1, ///< also ITU-R BT1361 / IEC 61966-2-4 / SMPTE
RP177 Annex B
+AVCOL_PRI_BT709 = 1, ///< also ITU-R BT1361 / IEC 61966-2-4 / SMPTE
RP 177 Annex B
AVCOL_PRI_UNSPECIFIED = 2,
AVCOL_PRI_RESERVED= 3,
AVCOL_PRI_BT470M = 4, ///< also FCC Title 47 Code of Federal
Regulations 73.682 (a)(20)
AVCOL_PRI_BT470BG = 5, ///< also ITU-R BT601-6 625 / ITU-R BT1358 625
/ ITU-R BT1700 625 PAL & SECAM
AVCOL_PRI_SMPTE170M = 6, ///< also ITU-R BT601-6 525 / ITU-R BT1358 525
/ ITU-R BT1700 NTSC
-AVCOL_PRI_SMPTE240M = 7, ///< functionally identical to above
+AVCOL_PRI_SMPTE240M = 7, ///< identical to above, also called "SMPTE C"
even though it uses D65
AVCOL_PRI_FILM= 8, ///< colour filters using Illuminant C
AVCOL_PRI_BT2020 = 9, ///< ITU-R BT2020
AVCOL_PRI_SMPTE428= 10, ///< SMPTE ST 428-1 (CIE 1931 XYZ)
AVCOL_PRI_SMPTEST428_1 = AVCOL_PRI_SMPTE428,
AVCOL_PRI_SMPTE431= 11, ///< SMPTE ST 431-2 (2011) / DCI P3
AVCOL_PRI_SMPTE432= 12, ///< SMPTE ST 432-1 (2010) / P3 D65 / Display
P3
-AVCOL_PRI_EBU3213 = 22, ///< EBU Tech. 3213-E / JEDEC P22 phosphors
+AVCOL_PRI_EBU3213 = 22, ///< EBU Tech. 3213-E (nothing there) / one of
JEDEC P22 group phosphors
AVCOL_PRI_JEDEC_P22 = AVCOL_PRI_EBU3213,
AVCOL_PRI_NB///< Not part of ABI
};
@@ -500,15 +500,15 @@ enum AVColorTransferCharacteristic {
* These values match the ones defined by ISO/IEC 23001-8_2013 § 7.3.
*/
enum AVColorSpace {
-AVCOL_SPC_RGB = 0, ///< order of coefficients is actually GBR,
also IEC 61966-2-1 (sRGB)
-AVCOL_SPC_BT709 = 1, ///< also ITU-R BT1361 / IEC 61966-2-4
xvYCC709 / SMPTE RP177 Annex B
+AVCOL_SPC_RGB = 0, ///< order of coefficients is actually GBR,
also IEC 61966-2-1 (sRGB), YZX and ST 428-1
+AVCOL_SPC_BT709 = 1, ///< also ITU-R BT1361 / IEC 61966-2-4
xvYCC709 / derived in SMPTE RP177 Annex B
AVCOL_SPC_UNSPECIFIED = 2,
-AVCOL_SPC_RESERVED= 3,
+AVCOL_SPC_RESERVED= 3, ///< reserved for future use by ITU-T and
ISO/IEC just like 15-255 are
AVCOL_SPC_FCC = 4, ///< FCC Title 47 Code of Federal Regulations
73.682 (a)(20)
AVCOL_SPC_BT470BG = 5, ///< also ITU-R BT601-6 625 / ITU-R BT1358 625
/ ITU-R BT1700 625 PAL & SECAM / IEC 61966-2-4 xvYCC601
-AVCOL_SPC_SMPTE170M = 6, ///< also ITU-R BT601-6 525 / ITU-R BT1358 525
/ ITU-R BT1700 NTSC
-AVCOL_SPC_SMPTE240M = 7, ///< functionally identical to above
-AVCOL_SPC_YCGCO = 8, ///< Used by Dirac / VC-2 and H.264 FRext, see
ITU-T SG16
+AVCOL_SPC_SMPTE170M = 6, ///< also ITU-R BT601-6 525 / ITU-R BT1358 525
/ ITU-R BT1700 NTSC / functionally identical to above
+AVCOL_SPC_SMPTE240M = 7, ///< derived from 170M primairies and D65
white point, 170M is derived from BT470 System M
+AVCOL_SPC_YCGCO = 8, ///< used by Dirac / VC-2 and H.264 FRext, see
ITU-T SG16
AVCOL_SPC_YCOCG = AVCOL_SPC_YCGCO,
AVCOL_SPC_BT2020_NCL = 9, ///< ITU-R BT2020 non-constant luminance system
AVCOL_SPC_BT2020_CL = 10, ///< ITU-R BT2020 constant luminance system
@@ -530,9 +530,9 @@ enum AVColorSpace {
* recommended, as it also defines the full range representation.
*
* Common definitions:
- * - For RGB and luminance planes such as Y in YCbCr and I in ICtCp,
+ * - For RGB and luma planes such as Y in YCbCr and I in ICtCp,
* 'E' is the original value in range of 0.0 to 1.0.
- * - For chrominance planes such as Cb,Cr and Ct,Cp, 'E' is the original
+ * - For chroma planes such as Cb,Cr and Ct,Cp, 'E' is the original
* value in range of -0.5 to 0.5.
* - 'n' is the output bit depth.
* - For additional definitions such as rounding and clipping to valid n
@@ -544,13 +544,13 @@ enum AVColorRange {
/**
* Narrow or limited range content.
*
- * - For luminance planes:
+
[FFmpeg-devel] [PATCH 2/2] fftools/ffprobe: 240M matrix is not the same as BT.601
---
fftools/ffplay.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/fftools/ffplay.c b/fftools/ffplay.c
index 0be1d90bf9..53bd9362fa 100644
--- a/fftools/ffplay.c
+++ b/fftools/ffplay.c
@@ -963,12 +963,12 @@ static void set_sdl_yuv_conversion_mode(AVFrame *frame)
if (frame && (frame->format == AV_PIX_FMT_YUV420P || frame->format ==
AV_PIX_FMT_YUYV422 || frame->format == AV_PIX_FMT_UYVY422)) {
if (frame->color_range == AVCOL_RANGE_JPEG)
mode = SDL_YUV_CONVERSION_JPEG;
-else if (frame->colorspace == AVCOL_SPC_BT709)
+else if (frame->colorspace == AVCOL_SPC_BT709) /* FIXME: sometimes it
selects this even for BT.601 matrix, see issue 8862 */
mode = SDL_YUV_CONVERSION_BT709;
-else if (frame->colorspace == AVCOL_SPC_BT470BG || frame->colorspace
== AVCOL_SPC_SMPTE170M || frame->colorspace == AVCOL_SPC_SMPTE240M)
+else if (frame->colorspace == AVCOL_SPC_BT470BG || frame->colorspace
== AVCOL_SPC_SMPTE170M)
mode = SDL_YUV_CONVERSION_BT601;
}
-SDL_SetYUVConversionMode(mode);
+SDL_SetYUVConversionMode(mode); /* FIXME: no support for linear transfer */
#endif
}
--
2.30.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 1/2] pixfmt: fixed wrong fix of comment
This mostly reverts 785bfb1d7bb8de567c3aac1d9cc369b55ac9fb7b.
But I also added some clarifications so that nobody mixes primaries
with matrix again. SMPTE 240 and 170 primaires are the same, while
matrix coeff. are different, because 240 is derived from 170's new
primaries and white point while 170 uses BT.601 derived from BT.470
System M (yes, with Illuminant C) a.k.a. NTSC 1953. Some nits too.
---
libavutil/pixfmt.h | 30 +++---
1 file changed, 15 insertions(+), 15 deletions(-)
diff --git a/libavutil/pixfmt.h b/libavutil/pixfmt.h
index 30591133a4..9513e88389 100644
--- a/libavutil/pixfmt.h
+++ b/libavutil/pixfmt.h
@@ -443,25 +443,25 @@ enum AVPixelFormat {
/**
* Chromaticity coordinates of the source primaries.
- * These values match the ones defined by ISO/IEC 23001-8_2013 § 7.1.
+ * These values match the ones defined by ISO/IEC 23001-8_2013 § 7.1 and
ITU-T H.273.
*/
enum AVColorPrimaries {
AVCOL_PRI_RESERVED0 = 0,
-AVCOL_PRI_BT709 = 1, ///< also ITU-R BT1361 / IEC 61966-2-4 / SMPTE
RP177 Annex B
+AVCOL_PRI_BT709 = 1, ///< also ITU-R BT1361 / IEC 61966-2-4 / SMPTE
RP 177 Annex B
AVCOL_PRI_UNSPECIFIED = 2,
AVCOL_PRI_RESERVED= 3,
AVCOL_PRI_BT470M = 4, ///< also FCC Title 47 Code of Federal
Regulations 73.682 (a)(20)
AVCOL_PRI_BT470BG = 5, ///< also ITU-R BT601-6 625 / ITU-R BT1358 625
/ ITU-R BT1700 625 PAL & SECAM
AVCOL_PRI_SMPTE170M = 6, ///< also ITU-R BT601-6 525 / ITU-R BT1358 525
/ ITU-R BT1700 NTSC
-AVCOL_PRI_SMPTE240M = 7, ///< functionally identical to above
+AVCOL_PRI_SMPTE240M = 7, ///< identical to above, also called "SMPTE C"
even though it uses D65
AVCOL_PRI_FILM= 8, ///< colour filters using Illuminant C
AVCOL_PRI_BT2020 = 9, ///< ITU-R BT2020
AVCOL_PRI_SMPTE428= 10, ///< SMPTE ST 428-1 (CIE 1931 XYZ)
AVCOL_PRI_SMPTEST428_1 = AVCOL_PRI_SMPTE428,
AVCOL_PRI_SMPTE431= 11, ///< SMPTE ST 431-2 (2011) / DCI P3
AVCOL_PRI_SMPTE432= 12, ///< SMPTE ST 432-1 (2010) / P3 D65 / Display
P3
-AVCOL_PRI_EBU3213 = 22, ///< EBU Tech. 3213-E / JEDEC P22 phosphors
+AVCOL_PRI_EBU3213 = 22, ///< EBU Tech. 3213-E (nothing there) / one of
JEDEC P22 group phosphors
AVCOL_PRI_JEDEC_P22 = AVCOL_PRI_EBU3213,
AVCOL_PRI_NB///< Not part of ABI
};
@@ -500,15 +500,15 @@ enum AVColorTransferCharacteristic {
* These values match the ones defined by ISO/IEC 23001-8_2013 § 7.3.
*/
enum AVColorSpace {
-AVCOL_SPC_RGB = 0, ///< order of coefficients is actually GBR,
also IEC 61966-2-1 (sRGB)
-AVCOL_SPC_BT709 = 1, ///< also ITU-R BT1361 / IEC 61966-2-4
xvYCC709 / SMPTE RP177 Annex B
+AVCOL_SPC_RGB = 0, ///< order of coefficients is actually GBR,
also IEC 61966-2-1 (sRGB), YZX and ST 428-1
+AVCOL_SPC_BT709 = 1, ///< also ITU-R BT1361 / IEC 61966-2-4
xvYCC709 / derived in SMPTE RP177 Annex B
AVCOL_SPC_UNSPECIFIED = 2,
-AVCOL_SPC_RESERVED= 3,
+AVCOL_SPC_RESERVED= 3, ///< reserved for future use by ITU-T and
ISO/IEC just like 15-255 are
AVCOL_SPC_FCC = 4, ///< FCC Title 47 Code of Federal Regulations
73.682 (a)(20)
AVCOL_SPC_BT470BG = 5, ///< also ITU-R BT601-6 625 / ITU-R BT1358 625
/ ITU-R BT1700 625 PAL & SECAM / IEC 61966-2-4 xvYCC601
-AVCOL_SPC_SMPTE170M = 6, ///< also ITU-R BT601-6 525 / ITU-R BT1358 525
/ ITU-R BT1700 NTSC
-AVCOL_SPC_SMPTE240M = 7, ///< functionally identical to above
-AVCOL_SPC_YCGCO = 8, ///< Used by Dirac / VC-2 and H.264 FRext, see
ITU-T SG16
+AVCOL_SPC_SMPTE170M = 6, ///< also ITU-R BT601-6 525 / ITU-R BT1358 525
/ ITU-R BT1700 NTSC / functionally identical to above
+AVCOL_SPC_SMPTE240M = 7, ///< derived from 170M primairies and D65
white point, 170M is derived from BT470 System M
+AVCOL_SPC_YCGCO = 8, ///< used by Dirac / VC-2 and H.264 FRext, see
ITU-T SG16
AVCOL_SPC_YCOCG = AVCOL_SPC_YCGCO,
AVCOL_SPC_BT2020_NCL = 9, ///< ITU-R BT2020 non-constant luminance system
AVCOL_SPC_BT2020_CL = 10, ///< ITU-R BT2020 constant luminance system
@@ -530,7 +530,7 @@ enum AVColorSpace {
* recommended, as it also defines the full range representation.
*
* Common definitions:
- * - For RGB and luminance planes such as Y in YCbCr and I in ICtCp,
+ * - For RGB and luma planes such as Y in YCbCr and I in ICtCp,
* 'E' is the original value in range of 0.0 to 1.0.
* - For chrominance planes such as Cb,Cr and Ct,Cp, 'E' is the original
* value in range of -0.5 to 0.5.
@@ -544,13 +544,13 @@ enum AVColorRange {
/**
* Narrow or limited range content.
*
- * - For luminance planes:
+ * - For luma planes:
*
* (219 * E + 16) * 2^(n-8)
*
* F.ex. the range of 16-235 for 8 bits
*
- * - For chrominance planes:
+ * - For chroma
[FFmpeg-devel] [PATCH v2] avcodec/j2kenc: fixed help for jpeg2000 dwt53
Now with cosmetics and two new defines.
---
libavcodec/j2kenc.c | 16
libavcodec/jpeg2000.h | 4
2 files changed, 12 insertions(+), 8 deletions(-)
diff --git a/libavcodec/j2kenc.c b/libavcodec/j2kenc.c
index 82ad3284b5..4d5022db26 100644
--- a/libavcodec/j2kenc.c
+++ b/libavcodec/j2kenc.c
@@ -1812,16 +1812,16 @@ static const AVOption options[] = {
{ "tile_width","Tile Width",OFFSET(tile_width),
AV_OPT_TYPE_INT, { .i64 = 256 }, 1, 1<<30, VE, },
{ "tile_height", "Tile Height", OFFSET(tile_height),
AV_OPT_TYPE_INT, { .i64 = 256 }, 1, 1<<30, VE, },
{ "pred", "DWT Type", OFFSET(pred),
AV_OPT_TYPE_INT, { .i64 = 0 }, 0, 1, VE, "pred"
},
-{ "dwt97int", NULL,0,
AV_OPT_TYPE_CONST, { .i64 = 0 }, INT_MIN, INT_MAX, VE, "pred"
},
-{ "dwt53", NULL,0,
AV_OPT_TYPE_CONST, { .i64 = 0 }, INT_MIN, INT_MAX, VE, "pred"
},
+{ "dwt97int", NULL,0,
AV_OPT_TYPE_CONST, { .i64 = JPEG2000_DWT97INT}, INT_MIN, INT_MAX, VE,
"pred"},
+{ "dwt53", NULL,0,
AV_OPT_TYPE_CONST, { .i64 = JPEG2000_DWT53 }, INT_MIN, INT_MAX, VE,
"pred"},
{ "sop", "SOP marker",OFFSET(sop),
AV_OPT_TYPE_INT, { .i64 = 0 }, 0, 1, VE, },
{ "eph", "EPH marker",OFFSET(eph),
AV_OPT_TYPE_INT, { .i64 = 0 }, 0, 1, VE, },
-{ "prog", "Progression Order", OFFSET(prog),
AV_OPT_TYPE_INT, { .i64 = 0 }, JPEG2000_PGOD_LRCP,
JPEG2000_PGOD_CPRL, VE, "prog" },
-{ "lrcp", NULL,OFFSET(prog),
AV_OPT_TYPE_CONST, { .i64 = JPEG2000_PGOD_LRCP }, 0, 0,
VE, "prog" },
-{ "rlcp", NULL,OFFSET(prog),
AV_OPT_TYPE_CONST, { .i64 = JPEG2000_PGOD_RLCP}, 0, 0,
VE, "prog" },
-{ "rpcl", NULL,OFFSET(prog),
AV_OPT_TYPE_CONST, { .i64 = JPEG2000_PGOD_RPCL}, 0, 0,
VE, "prog" },
-{ "pcrl", NULL,OFFSET(prog),
AV_OPT_TYPE_CONST, { .i64 = JPEG2000_PGOD_PCRL}, 0, 0,
VE, "prog" },
-{ "cprl", NULL,OFFSET(prog),
AV_OPT_TYPE_CONST, { .i64 = JPEG2000_PGOD_CPRL}, 0, 0,
VE, "prog" },
+{ "prog", "Progression Order", OFFSET(prog),
AV_OPT_TYPE_INT, { .i64 = 0 }, JPEG2000_PGOD_LRCP,
JPEG2000_PGOD_CPRL, VE, "prog" },
+{ "lrcp", NULL,OFFSET(prog),
AV_OPT_TYPE_CONST, { .i64 = JPEG2000_PGOD_LRCP}, 0, 0, VE,
"prog" },
+{ "rlcp", NULL,OFFSET(prog),
AV_OPT_TYPE_CONST, { .i64 = JPEG2000_PGOD_RLCP}, 0, 0, VE,
"prog" },
+{ "rpcl", NULL,OFFSET(prog),
AV_OPT_TYPE_CONST, { .i64 = JPEG2000_PGOD_RPCL}, 0, 0, VE,
"prog" },
+{ "pcrl", NULL,OFFSET(prog),
AV_OPT_TYPE_CONST, { .i64 = JPEG2000_PGOD_PCRL}, 0, 0, VE,
"prog" },
+{ "cprl", NULL,OFFSET(prog),
AV_OPT_TYPE_CONST, { .i64 = JPEG2000_PGOD_CPRL}, 0, 0, VE,
"prog" },
{ "layer_rates", "Layer Rates", OFFSET(lr_str),
AV_OPT_TYPE_STRING, { .str = NULL }, 0, 0, VE },
{ NULL }
};
diff --git a/libavcodec/jpeg2000.h b/libavcodec/jpeg2000.h
index 612832c872..1a37f0bbbe 100644
--- a/libavcodec/jpeg2000.h
+++ b/libavcodec/jpeg2000.h
@@ -111,6 +111,10 @@ enum Jpeg2000Quantsty { // quantization style
#define JPEG2000_CSTY_SOP 0x02 // SOP marker present
#define JPEG2000_CSTY_EPH 0x04 // EPH marker present
+// Lossy and lossless DWTs
+#define JPEG2000_DWT97INT 0x00 // lossy DWT
+#define JPEG2000_DWT53 0x01 // lossless DWT
+
// Progression orders
#define JPEG2000_PGOD_LRCP 0x00 // Layer-resolution
level-component-position progression
#define JPEG2000_PGOD_RLCP 0x01 // Resolution
level-layer-component-position progression
--
2.30.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] avformat/avio: fixed AVSEEK_FORCE and documentation
Always true expression: we would have returned on line 265.
Because of short curcuiting force will never be checked.
---
libavformat/avio.h| 1 -
libavformat/aviobuf.c | 3 +--
2 files changed, 1 insertion(+), 3 deletions(-)
diff --git a/libavformat/avio.h b/libavformat/avio.h
index d022820a6e..8bc00e3f3f 100644
--- a/libavformat/avio.h
+++ b/libavformat/avio.h
@@ -534,7 +534,6 @@ void avio_write_marker(AVIOContext *s, int64_t time, enum
AVIODataMarkerType typ
* Passing this flag as the "whence" parameter to a seek function causes it to
* seek by any means (like reopening and linear reading) or other normally
unreasonable
* means that can be extremely slow.
- * This may be ignored by the seek code.
*/
#define AVSEEK_FORCE 0x2
diff --git a/libavformat/aviobuf.c b/libavformat/aviobuf.c
index ddfa4ecbf1..d748cda397 100644
--- a/libavformat/aviobuf.c
+++ b/libavformat/aviobuf.c
@@ -286,8 +286,7 @@ int64_t avio_seek(AVIOContext *s, int64_t offset, int
whence)
} else if ((!(s->seekable & AVIO_SEEKABLE_NORMAL) ||
offset1 <= buffer_size + short_seek) &&
!s->write_flag && offset1 >= 0 &&
- (!s->direct || !s->seek) &&
- (whence != SEEK_END || force)) {
+ (!s->direct || !s->seek) || force) {
while(s->pos < offset && !s->eof_reached)
fill_buffer(s);
if (s->eof_reached)
--
2.30.2
___
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] avfilter/vf_hqdn3d: fix left shift of negative numbers
--- libavfilter/vf_hqdn3d.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libavfilter/vf_hqdn3d.c b/libavfilter/vf_hqdn3d.c index 8d71ae316d..bd3eb2d01c 100644 --- a/libavfilter/vf_hqdn3d.c +++ b/libavfilter/vf_hqdn3d.c @@ -179,7 +179,7 @@ static void precalc_coefs(double dist25, int depth, int16_t *ct) gamma = log(0.25) / log(1.0 - FFMIN(dist25,252.0)/255.0 - 0.1); -for (i = -256
[FFmpeg-devel] [PATCH] avfilter/src_movie: fix always true expression
Introduced in c1f9734f977f59bc0034096afbe8e43e40d93a5d.
We are in if (movie->seek_point > 0) but seek_point is timestamp.
---
libavfilter/src_movie.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavfilter/src_movie.c b/libavfilter/src_movie.c
index 54f6738f9a..105d1b7b54 100644
--- a/libavfilter/src_movie.c
+++ b/libavfilter/src_movie.c
@@ -252,7 +252,7 @@ static av_cold int movie_common_init(AVFilterContext *ctx)
timestamp = movie->seek_point;
// add the stream start time, should it exist
if (movie->format_ctx->start_time != AV_NOPTS_VALUE) {
-if (timestamp > 0 && movie->format_ctx->start_time > INT64_MAX -
timestamp) {
+if (movie->format_ctx->start_time > INT64_MAX - timestamp) {
av_log(ctx, AV_LOG_ERROR,
"%s: seek value overflow with start_time:%"PRId64"
seek_point:%"PRId64"\n",
movie->file_name, movie->format_ctx->start_time,
movie->seek_point);
--
2.30.2
___
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] lavfi/signature: fix always true expression
Otherwise since "==" has higher precedence, mode is never checked.
---
libavfilter/signature_lookup.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavfilter/signature_lookup.c b/libavfilter/signature_lookup.c
index 272c717c77..85e879d224 100644
--- a/libavfilter/signature_lookup.c
+++ b/libavfilter/signature_lookup.c
@@ -491,7 +491,7 @@ static MatchingInfo evaluate_parameters(AVFilterContext
*ctx, SignatureContext *
meandist = (double) goodfcount / (double) distsum;
if (meandist < minmeandist ||
-status == STATUS_END_REACHED | STATUS_BEGIN_REACHED ||
+status == (STATUS_END_REACHED | STATUS_BEGIN_REACHED) ||
mode == MODE_FAST){
minmeandist = meandist;
/* bestcandidate in this iteration */
--
2.30.2
___
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] lavfi/signature: fix always true expression
Otherwise since "==" has higher precedence, mode is never checked.
---
libavfilter/signature_lookup.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavfilter/signature_lookup.c b/libavfilter/signature_lookup.c
index 272c717c77..85e879d224 100644
--- a/libavfilter/signature_lookup.c
+++ b/libavfilter/signature_lookup.c
@@ -491,7 +491,7 @@ static MatchingInfo evaluate_parameters(AVFilterContext
*ctx, SignatureContext *
meandist = (double) goodfcount / (double) distsum;
if (meandist < minmeandist ||
-status == STATUS_END_REACHED | STATUS_BEGIN_REACHED ||
+status == (STATUS_END_REACHED | STATUS_BEGIN_REACHED) ||
mode == MODE_FAST){
minmeandist = meandist;
/* bestcandidate in this iteration */
--
2.30.2
___
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] libavformat/hlsenc: typos in comments
---
libavformat/hlsenc.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
index 5db7a744b4..151ef6ec8f 100644
--- a/libavformat/hlsenc.c
+++ b/libavformat/hlsenc.c
@@ -178,7 +178,7 @@ typedef struct VariantStream {
unsigned int nb_streams;
int m3u8_created; /* status of media play-list creation */
int is_default; /* default status of audio group */
-const char *language; /* audio lauguage name */
+const char *language; /* audio language name */
const char *agroup; /* audio group name */
const char *sgroup; /* subtitle group name */
const char *ccgroup; /* closed caption group name */
@@ -188,7 +188,7 @@ typedef struct VariantStream {
typedef struct ClosedCaptionsStream {
const char *ccgroup;/* closed caption group name */
const char *instreamid; /* closed captions INSTREAM-ID */
-const char *language; /* closed captions langauge */
+const char *language; /* closed captions language */
} ClosedCaptionsStream;
typedef struct HLSContext {
--
2.30.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] avcodec/j2kenc: fixed help for jpeg2000 dwt53
---
libavcodec/j2kenc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/j2kenc.c b/libavcodec/j2kenc.c
index 82ad3284b5..0b27f9adf5 100644
--- a/libavcodec/j2kenc.c
+++ b/libavcodec/j2kenc.c
@@ -1813,7 +1813,7 @@ static const AVOption options[] = {
{ "tile_height", "Tile Height", OFFSET(tile_height),
AV_OPT_TYPE_INT, { .i64 = 256 }, 1, 1<<30, VE, },
{ "pred", "DWT Type", OFFSET(pred),
AV_OPT_TYPE_INT, { .i64 = 0 }, 0, 1, VE, "pred"
},
{ "dwt97int", NULL,0,
AV_OPT_TYPE_CONST, { .i64 = 0 }, INT_MIN, INT_MAX, VE, "pred"
},
-{ "dwt53", NULL,0,
AV_OPT_TYPE_CONST, { .i64 = 0 }, INT_MIN, INT_MAX, VE, "pred"
},
+{ "dwt53", NULL,0,
AV_OPT_TYPE_CONST, { .i64 = 1 }, INT_MIN, INT_MAX, VE, "pred"
},
{ "sop", "SOP marker",OFFSET(sop),
AV_OPT_TYPE_INT, { .i64 = 0 }, 0, 1, VE, },
{ "eph", "EPH marker",OFFSET(eph),
AV_OPT_TYPE_INT, { .i64 = 0 }, 0, 1, VE, },
{ "prog", "Progression Order", OFFSET(prog),
AV_OPT_TYPE_INT, { .i64 = 0 }, JPEG2000_PGOD_LRCP,
JPEG2000_PGOD_CPRL, VE, "prog" },
--
2.30.2
___
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] libavcodec/dpxenc: change transfer/primaries to BT.709
--- libavcodec/dpxenc.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/libavcodec/dpxenc.c b/libavcodec/dpxenc.c index fa8b7d5ddc..db5ed4e328 100644 --- a/libavcodec/dpxenc.c +++ b/libavcodec/dpxenc.c @@ -219,8 +219,8 @@ static int encode_frame(AVCodecContext *avctx, AVPacket *pkt, write32(buf + 772, avctx->width); write32(buf + 776, avctx->height); buf[800] = s->descriptor; -buf[801] = 2; /* linear transfer */ -buf[802] = 2; /* linear colorimetric */ +buf[801] = 6; /* BT.709 transfer */ +buf[802] = 6; /* BT.709 primaries */ buf[803] = s->bits_per_component; write16(buf + 804, (s->bits_per_component == 10 || s->bits_per_component == 12) ? 1 : 0); /* packing method */ -- 2.30.2 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 1/2] avformat/pmpdec: AAC has been supported for a long time
--- libavformat/pmpdec.c | 1 - 1 file changed, 1 deletion(-) diff --git a/libavformat/pmpdec.c b/libavformat/pmpdec.c index ce8e89515a..a327f7f6de 100644 --- a/libavformat/pmpdec.c +++ b/libavformat/pmpdec.c @@ -82,7 +82,6 @@ static int pmp_header(AVFormatContext *s) audio_codec_id = AV_CODEC_ID_MP3; break; case 1: -av_log(s, AV_LOG_ERROR, "AAC not yet correctly supported\n"); audio_codec_id = AV_CODEC_ID_AAC; break; default: -- 2.30.2 ___ 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".
