[FFmpeg-devel] [PATCH] libavfilter/vf_hqdn3d: Remove emms
$subj 0001-libavfilter-vf_hqdn3d-Remove-emms.patch Description: Binary data ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] financial sustainability Plan A (SPI)
Thilo Borgmann via ffmpeg-devel 于2023年11月1日周三 08:04写道： > > > it would just show up once lets say on a specific day 1 year after the code > > is added. we would remove it on that day ourselfs. > > It would just be a simple one time shown message that says > > "Decoded by ffmpeg.org / Please donate, if you enjoy" > > Just my two cents and I admit I only flew over the last few mails. > Some visual output into the decoded streams or things alike (IIUC) should be a > nogo. Immediate memories about bad pirated movies comes to mind... so if this > is > the idea, we should really not do this, especially not (IIUC) if it would > occur > pseudo-randomly based on some time constraint. Agreed, i think show message about donation above or after banner is a good idea looks like vim. “ Help poor children in Uganda!” => “ Help poor developers in FFmpeg!” Thanks Steven ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] financial sustainability Plan A (SPI)
Am 31.10.23 um 18:48 schrieb Michael Niedermayer: On Tue, Oct 31, 2023 at 06:37:58PM +0100, Hendrik Leppkes wrote: On Tue, Oct 31, 2023 at 6:31 PM Michael Niedermayer wrote: On Tue, Oct 31, 2023 at 07:19:41PM +0200, Rémi Denis-Courmont wrote: Le tiistaina 31. lokakuuta 2023, 18.58.57 EET Michael Niedermayer a écrit : That's not a credible solution for a library. All reverse dependency developers would disable that before they ship affected FFmpeg versions, or worse, just stop updating their vendored FFmpeg. If its announced and we point to the commit, maybe half the minor users will remove it, maybe most of the bigger ones. If its not announced noone would remove it. companies do not audit the FFmpeg commits. They would remove it after seeing it but at that point it did what it intended to to, inform users again, like i said thats hypothetical and controversal. But basically doing the same as companies which put advertisements in without asking either creator nor viewer. How do you show ads without a GUI? Hijack the video signal from the decoder? In this very very hypothetical idea ... it would not be a add, but a simple information box shown briefly that says something like "decoded with ffmpeg.org, donate if you enjoy" / "encoded with ffmpeg.org, donate if you enjoy" If as a professional user of a decoder library, it starts putting in an ad or a watermark or whatever you want to call it, even if briefly, i'm looking for a new decoder library, or will venture to remove the message instantly. And if that wasn't enough to completely destroy the projects reputation, if you then try to hide it by randomizing or whatever, so that testing before deployment doesn't see it, that definitely will. This is not acceptable behavior for a decoder. And no "exposure" due like i said, its a hypothetical and controversal thought experiment to bad press will actually yield you a benefit. Companies won't pay you, because that doesn't get rid of the message. That misses the goal, the goal of this was to reach some of the more than 1 billion users we have and who do not know they are using FFmpeg. They'll pay an engineer to disable it. it would just show up once lets say on a specific day 1 year after the code is added. we would remove it on that day ourselfs. It would just be a simple one time shown message that says "Decoded by ffmpeg.org / Please donate, if you enjoy" Just my two cents and I admit I only flew over the last few mails. Some visual output into the decoded streams or things alike (IIUC) should be a nogo. Immediate memories about bad pirated movies comes to mind... so if this is the idea, we should really not do this, especially not (IIUC) if it would occur pseudo-randomly based on some time constraint. The one way I think this might be done, would be if we create a donations video filter to blend something like this in only if the user specifically adds this filter to their chain. In contrast, the idea of printing some "please donate" into the command line output I find quite ok. We could add one line with compressed info. The reach of that is big and should not offend any user at all (assuming it does also disappear if we set silent mode). How big this impact might be, was revealed by the deprication message libav added back in the days. Although it is of course not that news-worthy. -Thilo ___ 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 5/9] avcodec/vlc: Pass VLC_MULTI_ELEM directly not by pointer
On Tue, Oct 24, 2023 at 05:54:37AM -0400, Leo Izen wrote: > On 10/23/23 12:04, Michael Niedermayer wrote: > > On Mon, Oct 23, 2023 at 02:10:35AM -0400, Leo Izen wrote: > > > On 10/22/23 17:51, Michael Niedermayer wrote: > > > > This makes the code more testable as uninitialized fields are 0 > > > > and not random values from the last call > > > > > > > > Signed-off-by: Michael Niedermayer > > > > --- > > > >libavcodec/vlc.c | 14 +++--- > > > >1 file changed, 7 insertions(+), 7 deletions(-) > > > > > > > > diff --git a/libavcodec/vlc.c b/libavcodec/vlc.c > > > > index 9b7a42f79a3..4adec2da705 100644 > > > > --- a/libavcodec/vlc.c > > > > +++ b/libavcodec/vlc.c > > > > @@ -356,7 +356,7 @@ static void add_level(VLC_MULTI_ELEM *table, const > > > > int is16bit, > > > > uint32_t curcode, int curlen, > > > > int curlimit, int curlevel, > > > > const int minlen, const int max, > > > > - unsigned* levelcnt, VLC_MULTI_ELEM *info) > > > > + unsigned* levelcnt, VLC_MULTI_ELEM info) > > > > > > > > > Is passing a struct by value advisable? Did you benchmark this? How does > > > it > > > compare to memset(info, 0, sizeof(*info))? > > > > The struct is 8 bytes, a pointer on 64bit arch is also 8byte > > > > I did not benchmark, I think this code doesnt run that many iterations > > (when its not buggy), I mean each iteration adds a entry to the table > > and the table will normally be designed to fit in cache and its only > > for initializing. > > > > do you still want me to bechmark this ? > > > > thx > > > > If the struct is only 8 bytes it's probably not necessary. will apply patches 3-5 thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Concerning the gods, I have no means of knowing whether they exist or not or of what sort they may be, because of the obscurity of the subject, and the brevity of human life -- Protagoras signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/6] avformat/mov: Check that is_still_picture_avif has no trak based streams
On Sun, Oct 22, 2023 at 02:35:15AM +0200, Michael Niedermayer wrote: > Fixes: Assertion failure in mov_read_iloc( in mov_read_iloc()) > Fixes: > 62866/clusterfuzz-testcase-minimized-ffmpeg_dem_MOV_fuzzer-5282997370486784 > > Found-by: continuous fuzzing process > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg > Signed-off-by: Michael Niedermayer > --- > libavformat/mov.c | 4 > 1 file changed, 4 insertions(+) will apply patches of this set that have received no comment [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The greatest way to live with honor in this world is to be what we pretend to be. -- Socrates 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 3/3] avcodec/evc_parse: Check tid
On Fri, Oct 27, 2023 at 03:02:27PM +0200, Dawid Kozinski/Multimedia (PLT)
/SRPOL/Staff Engineer/Samsung Electronics wrote:
>
>
>
>
> > -Original Message-
> > From: ffmpeg-devel On Behalf Of
> > Michael Niedermayer
> > Sent: piątek, 13 października 2023 01:28
> > To: FFmpeg development discussions and patches
> > Subject: [FFmpeg-devel] [PATCH 3/3] avcodec/evc_parse: Check tid
> >
> > The check is based on not infinite looping. It is likely a more strict
> check can be
> > done
> >
> > Fixes: Infinite loop
> > Fixes: 62473/clusterfuzz-testcase-minimized-
> > ffmpeg_BSF_EVC_FRAME_MERGE_fuzzer-5719883750703104
> > Fixes: 62765/clusterfuzz-testcase-minimized-ffmpeg_dem_EVC_fuzzer-
> > 6448531252314112
> >
> > Found-by: continuous fuzzing process
> > https://protect2.fireeye.com/v1/url?k=06e4faf3-676fefea-06e571bc-
> > 74fe485cbfec-11816a289a0e9c00=1=16696cd9-38c1-42d0-9196-
> > 8ad7c6d1d0d6=https%3A%2F%2Fgithub.com%2Fgoogle%2Foss-
> > fuzz%2Ftree%2Fmaster%2Fprojects%2Fffmpeg
> > Signed-off-by: Michael Niedermayer
> > ---
> > libavcodec/evc_parse.c | 3 +++
> > 1 file changed, 3 insertions(+)
> >
> > diff --git a/libavcodec/evc_parse.c b/libavcodec/evc_parse.c index
> > 255706ce61..43b8dabf8b 100644
> > --- a/libavcodec/evc_parse.c
> > +++ b/libavcodec/evc_parse.c
> > @@ -174,6 +174,9 @@ int ff_evc_derive_poc(const EVCParamSets *ps, const
> > EVCParserSliceHeader *sh,
> > } else {
> > int SubGopLength = 1 << sps->log2_sub_gop_length;
> >
> > +if (tid > (SubGopLength > 1 ? 1 + av_log2(SubGopLength - 1) :
> 0))
> > +return AVERROR_INVALIDDATA;
> > +
> > if (tid == 0) {
> > poc->PicOrderCntVal = poc->prevPicOrderCntVal +
> SubGopLength;
> > poc->DocOffset = 0;
> > --
>
>
> Looks good
will apply
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
The educated differ from the uneducated as much as the living from the
dead. -- Aristotle
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avfillter/buffersrc: activate and EOF fix
On Tue, Oct 31, 2023 at 9:13 PM Paul B Mahol wrote: > > > On Tue, Oct 31, 2023 at 11:55 AM Nicolas George wrote: > >> Paul B Mahol (12023-10-27): >> > Both patches are required to fix out of memory scenario with this use >> case: >> >> I checked. The OOM still happens with these two patches => they do not >> fix the issue => rejected. >> > > Huh? I fixed this, and you need to give proof that this does not fixes it. > Because You can be mistaken and/or evil and simply lie. > Also, JEEB tested it and it also fixes it for him. So I really wonder how you tested this. > > >> >> > This was a test. That you failed. >> >> Are you sure you are mature enough to go on the Internet unsupervised? >> >> -- >> 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". >> > ___ 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] avfillter/buffersrc: activate and EOF fix
On Tue, Oct 31, 2023 at 11:55 AM Nicolas George wrote: > Paul B Mahol (12023-10-27): > > Both patches are required to fix out of memory scenario with this use > case: > > I checked. The OOM still happens with these two patches => they do not > fix the issue => rejected. > Huh? I fixed this, and you need to give proof that this does not fixes it. Because You can be mistaken and/or evil and simply lie. > > > This was a test. That you failed. > > Are you sure you are mature enough to go on the Internet unsupervised? > > -- > 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". > ___ 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 10bit support v5 3/3] avcodec/amfenc: add 10 bit encoding in av1_amf
v2: refactored after review
Signed-off-by: Evgeny Pavlov
Co-authored-by: Dmitrii Ovchinnikov
---
libavcodec/amfenc.c | 2 ++
libavcodec/amfenc_av1.c | 22 ++
2 files changed, 24 insertions(+)
diff --git a/libavcodec/amfenc.c b/libavcodec/amfenc.c
index 068bb53002..f1b76bd6aa 100644
--- a/libavcodec/amfenc.c
+++ b/libavcodec/amfenc.c
@@ -826,6 +826,8 @@ int ff_amf_receive_packet(AVCodecContext *avctx, AVPacket
*avpkt)
AMF_ASSIGN_PROPERTY_INTERFACE(res, ctx->encoder,
AMF_VIDEO_ENCODER_INPUT_HDR_METADATA, hdrmeta_buffer); break;
case AV_CODEC_ID_HEVC:
AMF_ASSIGN_PROPERTY_INTERFACE(res, ctx->encoder,
AMF_VIDEO_ENCODER_HEVC_INPUT_HDR_METADATA, hdrmeta_buffer); break;
+case AV_CODEC_ID_AV1:
+AMF_ASSIGN_PROPERTY_INTERFACE(res, ctx->encoder,
AMF_VIDEO_ENCODER_AV1_INPUT_HDR_METADATA, hdrmeta_buffer); break;
}
hdrmeta_buffer->pVtbl->Release(hdrmeta_buffer);
}
diff --git a/libavcodec/amfenc_av1.c b/libavcodec/amfenc_av1.c
index 8f13aea29e..634eeea48f 100644
--- a/libavcodec/amfenc_av1.c
+++ b/libavcodec/amfenc_av1.c
@@ -165,6 +165,9 @@ static av_cold int amf_encode_init_av1(AVCodecContext*
avctx)
AMFGuid guid;
AMFRate framerate;
AMFSize framesize = AMFConstructSize(avctx->width,
avctx->height);
+amf_int64 color_depth;
+amf_int64 color_profile;
+enumAVPixelFormat pix_fmt;
@@ -203,6 +206,25 @@ FF_ENABLE_DEPRECATION_WARNINGS
}
AMF_ASSIGN_PROPERTY_INT64(res, ctx->encoder,
AMF_VIDEO_ENCODER_AV1_PROFILE, profile);
+/// Color profile
+color_profile = ff_amf_get_color_profile(avctx);
+AMF_ASSIGN_PROPERTY_INT64(res, ctx->encoder,
AMF_VIDEO_ENCODER_AV1_OUTPUT_COLOR_PROFILE, color_profile);
+
+/// Color Depth
+pix_fmt = avctx->hw_frames_ctx ?
((AVHWFramesContext*)avctx->hw_frames_ctx->data)->sw_format
+: avctx->pix_fmt;
+color_depth = AMF_COLOR_BIT_DEPTH_8;
+if (pix_fmt == AV_PIX_FMT_P010) {
+color_depth = AMF_COLOR_BIT_DEPTH_10;
+}
+
+AMF_ASSIGN_PROPERTY_INT64(res, ctx->encoder,
AMF_VIDEO_ENCODER_AV1_COLOR_BIT_DEPTH, color_depth);
+AMF_ASSIGN_PROPERTY_INT64(res, ctx->encoder,
AMF_VIDEO_ENCODER_AV1_OUTPUT_COLOR_PROFILE, color_profile);
+/// Color Transfer Characteristics (AMF matches ISO/IEC)
+AMF_ASSIGN_PROPERTY_INT64(res, ctx->encoder,
AMF_VIDEO_ENCODER_AV1_OUTPUT_TRANSFER_CHARACTERISTIC,
(amf_int64)avctx->color_trc);
+/// Color Primaries (AMF matches ISO/IEC)
+AMF_ASSIGN_PROPERTY_INT64(res, ctx->encoder,
AMF_VIDEO_ENCODER_AV1_OUTPUT_COLOR_PRIMARIES,
(amf_int64)avctx->color_primaries);
+
profile_level = avctx->level;
if (profile_level == AV_LEVEL_UNKNOWN) {
profile_level = ctx->level;
--
2.41.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 10 bit support v5 2/3] avcodec/amfenc: HDR metadata.
From: nyanmisaka
v2: fixes for indentation
---
libavcodec/amfenc.c | 83 +
1 file changed, 83 insertions(+)
diff --git a/libavcodec/amfenc.c b/libavcodec/amfenc.c
index 0bd15dd812..068bb53002 100644
--- a/libavcodec/amfenc.c
+++ b/libavcodec/amfenc.c
@@ -36,6 +36,57 @@
#include "amfenc.h"
#include "encode.h"
#include "internal.h"
+#include "libavutil/mastering_display_metadata.h"
+
+static int amf_save_hdr_metadata(AVCodecContext *avctx, const AVFrame *frame,
AMFHDRMetadata *hdrmeta)
+{
+AVFrameSideData*sd_display;
+AVFrameSideData*sd_light;
+AVMasteringDisplayMetadata *display_meta;
+AVContentLightMetadata *light_meta;
+
+sd_display = av_frame_get_side_data(frame,
AV_FRAME_DATA_MASTERING_DISPLAY_METADATA);
+if (sd_display) {
+display_meta = (AVMasteringDisplayMetadata *)sd_display->data;
+if (display_meta->has_luminance) {
+const unsigned int luma_den = 1;
+hdrmeta->maxMasteringLuminance =
+(amf_uint32)(luma_den * av_q2d(display_meta->max_luminance));
+hdrmeta->minMasteringLuminance =
+FFMIN((amf_uint32)(luma_den *
av_q2d(display_meta->min_luminance)), hdrmeta->maxMasteringLuminance);
+}
+if (display_meta->has_primaries) {
+const unsigned int chroma_den = 5;
+hdrmeta->redPrimary[0] =
+FFMIN((amf_uint16)(chroma_den *
av_q2d(display_meta->display_primaries[0][0])), chroma_den);
+hdrmeta->redPrimary[1] =
+FFMIN((amf_uint16)(chroma_den *
av_q2d(display_meta->display_primaries[0][1])), chroma_den);
+hdrmeta->greenPrimary[0] =
+FFMIN((amf_uint16)(chroma_den *
av_q2d(display_meta->display_primaries[1][0])), chroma_den);
+hdrmeta->greenPrimary[1] =
+FFMIN((amf_uint16)(chroma_den *
av_q2d(display_meta->display_primaries[1][1])), chroma_den);
+hdrmeta->bluePrimary[0] =
+FFMIN((amf_uint16)(chroma_den *
av_q2d(display_meta->display_primaries[2][0])), chroma_den);
+hdrmeta->bluePrimary[1] =
+FFMIN((amf_uint16)(chroma_den *
av_q2d(display_meta->display_primaries[2][1])), chroma_den);
+hdrmeta->whitePoint[0] =
+FFMIN((amf_uint16)(chroma_den *
av_q2d(display_meta->white_point[0])), chroma_den);
+hdrmeta->whitePoint[1] =
+FFMIN((amf_uint16)(chroma_den *
av_q2d(display_meta->white_point[1])), chroma_den);
+}
+
+sd_light = av_frame_get_side_data(frame,
AV_FRAME_DATA_CONTENT_LIGHT_LEVEL);
+if (sd_light) {
+light_meta = (AVContentLightMetadata *)sd_light->data;
+if (light_meta) {
+hdrmeta->maxContentLightLevel = (amf_uint16)light_meta->MaxCLL;
+hdrmeta->maxFrameAverageLightLevel =
(amf_uint16)light_meta->MaxFALL;
+}
+}
+return 0;
+}
+return 1;
+}
#if CONFIG_D3D11VA
#include
@@ -683,6 +734,26 @@ int ff_amf_receive_packet(AVCodecContext *avctx, AVPacket
*avpkt)
frame_ref_storage_buffer->pVtbl->Release(frame_ref_storage_buffer);
}
+// HDR10 metadata
+if (frame->color_trc == AVCOL_TRC_SMPTE2084) {
+AMFBuffer * hdrmeta_buffer = NULL;
+res = ctx->context->pVtbl->AllocBuffer(ctx->context,
AMF_MEMORY_HOST, sizeof(AMFHDRMetadata), _buffer);
+if (res == AMF_OK) {
+AMFHDRMetadata * hdrmeta =
(AMFHDRMetadata*)hdrmeta_buffer->pVtbl->GetNative(hdrmeta_buffer);
+if (amf_save_hdr_metadata(avctx, frame, hdrmeta) == 0) {
+switch (avctx->codec->id) {
+case AV_CODEC_ID_H264:
+AMF_ASSIGN_PROPERTY_INTERFACE(res, ctx->encoder,
AMF_VIDEO_ENCODER_INPUT_HDR_METADATA, hdrmeta_buffer); break;
+case AV_CODEC_ID_HEVC:
+AMF_ASSIGN_PROPERTY_INTERFACE(res, ctx->encoder,
AMF_VIDEO_ENCODER_HEVC_INPUT_HDR_METADATA, hdrmeta_buffer); break;
+}
+res = amf_set_property_buffer(surface,
L"av_frame_hdrmeta", hdrmeta_buffer);
+AMF_RETURN_IF_FALSE(avctx, res == AMF_OK, AVERROR_UNKNOWN,
"SetProperty failed for \"av_frame_hdrmeta\" with error %d\n", res);
+}
+hdrmeta_buffer->pVtbl->Release(hdrmeta_buffer);
+}
+}
+
surface->pVtbl->SetPts(surface, frame->pts);
AMF_ASSIGN_PROPERTY_INT64(res, surface, PTS_PROP, frame->pts);
@@ -746,6 +817,18 @@ int ff_amf_receive_packet(AVCodecContext *avctx, AVPacket
*avpkt)
}
res_resubmit = AMF_OK;
if (ctx->delayed_surface != NULL) { // try to resubmit frame
+if (ctx->delayed_surface->pVtbl->HasProperty(ctx->delayed_surface,
L"av_frame_hdrmeta")) {
+AMFBuffer *
[FFmpeg-devel] [PATCH 10 bit support v5 1/3] avcodec/amfenc: Fixes the color information in the output.
From: Michael Fabian 'Xaymar' Dirks
added 10 bit support for amf hevc.
before:
command - ffmpeg.exe -hide_banner -y -hwaccel d3d11va -hwaccel_output_format
d3d11 -i test_10bit_file.mkv -an -c:v h264_amf res.dx11_hw_h264.mkv
output - Format of input frames context (p010le) is not supported by AMF.
command - ffmpeg.exe -hide_banner -y -hwaccel d3d11va -hwaccel_output_format
d3d11 -i test_10bit_file -an -c:v hevc_amf res.dx11_hw_hevc.mkv
output - Format of input frames context (p010le) is not supported by AMF.
after:
command - ffmpeg.exe -hide_banner -y -hwaccel d3d11va -hwaccel_output_format
d3d11 -i test_10bit_file -an -c:v h264_amf res.dx11_hw_h264.mkv
output - 10-bit input video is not supported by AMF H264 encoder
command - ffmpeg.exe -hide_banner -y -hwaccel d3d11va -hwaccel_output_format
d3d11 -i test_10bit_file -an -c:v hevc_amf res.dx11_hw_hevc.mkv
output - 10bit file
v2 - lost line returned in ff_amf_pix_fmts
v3 - fixes after review
v4 - extract duplicated code, fix incorrect processing of 10-bit input for h264
v5 - non-functional changes after review
Co-authored-by: Evgeny Pavlov
---
libavcodec/amfenc.c | 37 +
libavcodec/amfenc.h | 3 +++
libavcodec/amfenc_h264.c | 24
libavcodec/amfenc_hevc.c | 26 +-
4 files changed, 85 insertions(+), 5 deletions(-)
diff --git a/libavcodec/amfenc.c b/libavcodec/amfenc.c
index 061859f85c..0bd15dd812 100644
--- a/libavcodec/amfenc.c
+++ b/libavcodec/amfenc.c
@@ -60,6 +60,7 @@ const enum AVPixelFormat ff_amf_pix_fmts[] = {
#if CONFIG_DXVA2
AV_PIX_FMT_DXVA2_VLD,
#endif
+AV_PIX_FMT_P010,
AV_PIX_FMT_NONE
};
@@ -72,6 +73,7 @@ static const FormatMap format_map[] =
{
{ AV_PIX_FMT_NONE, AMF_SURFACE_UNKNOWN },
{ AV_PIX_FMT_NV12, AMF_SURFACE_NV12 },
+{ AV_PIX_FMT_P010, AMF_SURFACE_P010 },
{ AV_PIX_FMT_BGR0, AMF_SURFACE_BGRA },
{ AV_PIX_FMT_RGB0, AMF_SURFACE_RGBA },
{ AV_PIX_FMT_GRAY8, AMF_SURFACE_GRAY8 },
@@ -785,6 +787,41 @@ int ff_amf_receive_packet(AVCodecContext *avctx, AVPacket
*avpkt)
return ret;
}
+int ff_amf_get_color_profile(AVCodecContext *avctx)
+{
+amf_int64 color_profile = AMF_VIDEO_CONVERTER_COLOR_PROFILE_UNKNOWN;
+if (avctx->color_range == AVCOL_RANGE_JPEG) {
+/// Color Space for Full (JPEG) Range
+switch (avctx->colorspace) {
+case AVCOL_SPC_SMPTE170M:
+color_profile = AMF_VIDEO_CONVERTER_COLOR_PROFILE_FULL_601;
+break;
+case AVCOL_SPC_BT709:
+color_profile = AMF_VIDEO_CONVERTER_COLOR_PROFILE_FULL_709;
+break;
+case AVCOL_SPC_BT2020_NCL:
+case AVCOL_SPC_BT2020_CL:
+color_profile = AMF_VIDEO_CONVERTER_COLOR_PROFILE_FULL_2020;
+break;
+}
+} else {
+/// Color Space for Limited (MPEG) range
+switch (avctx->colorspace) {
+case AVCOL_SPC_SMPTE170M:
+color_profile = AMF_VIDEO_CONVERTER_COLOR_PROFILE_601;
+break;
+case AVCOL_SPC_BT709:
+color_profile = AMF_VIDEO_CONVERTER_COLOR_PROFILE_709;
+break;
+case AVCOL_SPC_BT2020_NCL:
+case AVCOL_SPC_BT2020_CL:
+color_profile = AMF_VIDEO_CONVERTER_COLOR_PROFILE_2020;
+break;
+}
+}
+return color_profile;
+}
+
const AVCodecHWConfigInternal *const ff_amfenc_hw_configs[] = {
#if CONFIG_D3D11VA
HW_CONFIG_ENCODER_FRAMES(D3D11, D3D11VA),
diff --git a/libavcodec/amfenc.h b/libavcodec/amfenc.h
index 2dbd378ef8..62736ef579 100644
--- a/libavcodec/amfenc.h
+++ b/libavcodec/amfenc.h
@@ -21,6 +21,7 @@
#include
+#include
#include
#include
#include
@@ -170,6 +171,8 @@ int ff_amf_receive_packet(AVCodecContext *avctx, AVPacket
*avpkt);
*/
extern const enum AVPixelFormat ff_amf_pix_fmts[];
+int ff_amf_get_color_profile(AVCodecContext *avctx);
+
/**
* Error handling helper
*/
diff --git a/libavcodec/amfenc_h264.c b/libavcodec/amfenc_h264.c
index bd544d12df..f785e091c9 100644
--- a/libavcodec/amfenc_h264.c
+++ b/libavcodec/amfenc_h264.c
@@ -199,6 +199,8 @@ static av_cold int amf_encode_init_h264(AVCodecContext
*avctx)
AMFRate framerate;
AMFSize framesize =
AMFConstructSize(avctx->width, avctx->height);
int deblocking_filter = (avctx->flags &
AV_CODEC_FLAG_LOOP_FILTER) ? 1 : 0;
+amf_int64color_profile;
+enum AVPixelFormat pix_fmt;
if (avctx->framerate.num > 0 && avctx->framerate.den > 0) {
framerate = AMFConstructRate(avctx->framerate.num,
avctx->framerate.den);
@@ -262,10 +264,24 @@ FF_ENABLE_DEPRECATION_WARNINGS
AMF_ASSIGN_PROPERTY_RATIO(res, ctx->encoder,
AMF_VIDEO_ENCODER_ASPECT_RATIO, ratio);
}
-/// Color Range (Partial/TV/MPEG or Full/PC/JPEG)
-
[FFmpeg-devel] [PATCH 10bit support v5 3/3] avcodec/amfenc: add 10 bit encoding in av1_amf
v2: refactored after review
Signed-off-by: Evgeny Pavlov
Co-authored-by: Dmitrii Ovchinnikov
---
libavcodec/amfenc.c | 2 ++
libavcodec/amfenc_av1.c | 22 ++
2 files changed, 24 insertions(+)
diff --git a/libavcodec/amfenc.c b/libavcodec/amfenc.c
index 068bb53002..f1b76bd6aa 100644
--- a/libavcodec/amfenc.c
+++ b/libavcodec/amfenc.c
@@ -826,6 +826,8 @@ int ff_amf_receive_packet(AVCodecContext *avctx, AVPacket
*avpkt)
AMF_ASSIGN_PROPERTY_INTERFACE(res, ctx->encoder,
AMF_VIDEO_ENCODER_INPUT_HDR_METADATA, hdrmeta_buffer); break;
case AV_CODEC_ID_HEVC:
AMF_ASSIGN_PROPERTY_INTERFACE(res, ctx->encoder,
AMF_VIDEO_ENCODER_HEVC_INPUT_HDR_METADATA, hdrmeta_buffer); break;
+case AV_CODEC_ID_AV1:
+AMF_ASSIGN_PROPERTY_INTERFACE(res, ctx->encoder,
AMF_VIDEO_ENCODER_AV1_INPUT_HDR_METADATA, hdrmeta_buffer); break;
}
hdrmeta_buffer->pVtbl->Release(hdrmeta_buffer);
}
diff --git a/libavcodec/amfenc_av1.c b/libavcodec/amfenc_av1.c
index 8f13aea29e..634eeea48f 100644
--- a/libavcodec/amfenc_av1.c
+++ b/libavcodec/amfenc_av1.c
@@ -165,6 +165,9 @@ static av_cold int amf_encode_init_av1(AVCodecContext*
avctx)
AMFGuid guid;
AMFRate framerate;
AMFSize framesize = AMFConstructSize(avctx->width,
avctx->height);
+amf_int64 color_depth;
+amf_int64 color_profile;
+enumAVPixelFormat pix_fmt;
@@ -203,6 +206,25 @@ FF_ENABLE_DEPRECATION_WARNINGS
}
AMF_ASSIGN_PROPERTY_INT64(res, ctx->encoder,
AMF_VIDEO_ENCODER_AV1_PROFILE, profile);
+/// Color profile
+color_profile = ff_amf_get_color_profile(avctx);
+AMF_ASSIGN_PROPERTY_INT64(res, ctx->encoder,
AMF_VIDEO_ENCODER_AV1_OUTPUT_COLOR_PROFILE, color_profile);
+
+/// Color Depth
+pix_fmt = avctx->hw_frames_ctx ?
((AVHWFramesContext*)avctx->hw_frames_ctx->data)->sw_format
+: avctx->pix_fmt;
+color_depth = AMF_COLOR_BIT_DEPTH_8;
+if (pix_fmt == AV_PIX_FMT_P010) {
+color_depth = AMF_COLOR_BIT_DEPTH_10;
+}
+
+AMF_ASSIGN_PROPERTY_INT64(res, ctx->encoder,
AMF_VIDEO_ENCODER_AV1_COLOR_BIT_DEPTH, color_depth);
+AMF_ASSIGN_PROPERTY_INT64(res, ctx->encoder,
AMF_VIDEO_ENCODER_AV1_OUTPUT_COLOR_PROFILE, color_profile);
+/// Color Transfer Characteristics (AMF matches ISO/IEC)
+AMF_ASSIGN_PROPERTY_INT64(res, ctx->encoder,
AMF_VIDEO_ENCODER_AV1_OUTPUT_TRANSFER_CHARACTERISTIC,
(amf_int64)avctx->color_trc);
+/// Color Primaries (AMF matches ISO/IEC)
+AMF_ASSIGN_PROPERTY_INT64(res, ctx->encoder,
AMF_VIDEO_ENCODER_AV1_OUTPUT_COLOR_PRIMARIES,
(amf_int64)avctx->color_primaries);
+
profile_level = avctx->level;
if (profile_level == AV_LEVEL_UNKNOWN) {
profile_level = ctx->level;
--
2.41.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 10 bit support v5 2/3] avcodec/amfenc: HDR metadata.
From: nyanmisaka
v2: fixes for indentation
---
libavcodec/amfenc.c | 83 +
1 file changed, 83 insertions(+)
diff --git a/libavcodec/amfenc.c b/libavcodec/amfenc.c
index 0bd15dd812..068bb53002 100644
--- a/libavcodec/amfenc.c
+++ b/libavcodec/amfenc.c
@@ -36,6 +36,57 @@
#include "amfenc.h"
#include "encode.h"
#include "internal.h"
+#include "libavutil/mastering_display_metadata.h"
+
+static int amf_save_hdr_metadata(AVCodecContext *avctx, const AVFrame *frame,
AMFHDRMetadata *hdrmeta)
+{
+AVFrameSideData*sd_display;
+AVFrameSideData*sd_light;
+AVMasteringDisplayMetadata *display_meta;
+AVContentLightMetadata *light_meta;
+
+sd_display = av_frame_get_side_data(frame,
AV_FRAME_DATA_MASTERING_DISPLAY_METADATA);
+if (sd_display) {
+display_meta = (AVMasteringDisplayMetadata *)sd_display->data;
+if (display_meta->has_luminance) {
+const unsigned int luma_den = 1;
+hdrmeta->maxMasteringLuminance =
+(amf_uint32)(luma_den * av_q2d(display_meta->max_luminance));
+hdrmeta->minMasteringLuminance =
+FFMIN((amf_uint32)(luma_den *
av_q2d(display_meta->min_luminance)), hdrmeta->maxMasteringLuminance);
+}
+if (display_meta->has_primaries) {
+const unsigned int chroma_den = 5;
+hdrmeta->redPrimary[0] =
+FFMIN((amf_uint16)(chroma_den *
av_q2d(display_meta->display_primaries[0][0])), chroma_den);
+hdrmeta->redPrimary[1] =
+FFMIN((amf_uint16)(chroma_den *
av_q2d(display_meta->display_primaries[0][1])), chroma_den);
+hdrmeta->greenPrimary[0] =
+FFMIN((amf_uint16)(chroma_den *
av_q2d(display_meta->display_primaries[1][0])), chroma_den);
+hdrmeta->greenPrimary[1] =
+FFMIN((amf_uint16)(chroma_den *
av_q2d(display_meta->display_primaries[1][1])), chroma_den);
+hdrmeta->bluePrimary[0] =
+FFMIN((amf_uint16)(chroma_den *
av_q2d(display_meta->display_primaries[2][0])), chroma_den);
+hdrmeta->bluePrimary[1] =
+FFMIN((amf_uint16)(chroma_den *
av_q2d(display_meta->display_primaries[2][1])), chroma_den);
+hdrmeta->whitePoint[0] =
+FFMIN((amf_uint16)(chroma_den *
av_q2d(display_meta->white_point[0])), chroma_den);
+hdrmeta->whitePoint[1] =
+FFMIN((amf_uint16)(chroma_den *
av_q2d(display_meta->white_point[1])), chroma_den);
+}
+
+sd_light = av_frame_get_side_data(frame,
AV_FRAME_DATA_CONTENT_LIGHT_LEVEL);
+if (sd_light) {
+light_meta = (AVContentLightMetadata *)sd_light->data;
+if (light_meta) {
+hdrmeta->maxContentLightLevel = (amf_uint16)light_meta->MaxCLL;
+hdrmeta->maxFrameAverageLightLevel =
(amf_uint16)light_meta->MaxFALL;
+}
+}
+return 0;
+}
+return 1;
+}
#if CONFIG_D3D11VA
#include
@@ -683,6 +734,26 @@ int ff_amf_receive_packet(AVCodecContext *avctx, AVPacket
*avpkt)
frame_ref_storage_buffer->pVtbl->Release(frame_ref_storage_buffer);
}
+// HDR10 metadata
+if (frame->color_trc == AVCOL_TRC_SMPTE2084) {
+AMFBuffer * hdrmeta_buffer = NULL;
+res = ctx->context->pVtbl->AllocBuffer(ctx->context,
AMF_MEMORY_HOST, sizeof(AMFHDRMetadata), _buffer);
+if (res == AMF_OK) {
+AMFHDRMetadata * hdrmeta =
(AMFHDRMetadata*)hdrmeta_buffer->pVtbl->GetNative(hdrmeta_buffer);
+if (amf_save_hdr_metadata(avctx, frame, hdrmeta) == 0) {
+switch (avctx->codec->id) {
+case AV_CODEC_ID_H264:
+AMF_ASSIGN_PROPERTY_INTERFACE(res, ctx->encoder,
AMF_VIDEO_ENCODER_INPUT_HDR_METADATA, hdrmeta_buffer); break;
+case AV_CODEC_ID_HEVC:
+AMF_ASSIGN_PROPERTY_INTERFACE(res, ctx->encoder,
AMF_VIDEO_ENCODER_HEVC_INPUT_HDR_METADATA, hdrmeta_buffer); break;
+}
+res = amf_set_property_buffer(surface,
L"av_frame_hdrmeta", hdrmeta_buffer);
+AMF_RETURN_IF_FALSE(avctx, res == AMF_OK, AVERROR_UNKNOWN,
"SetProperty failed for \"av_frame_hdrmeta\" with error %d\n", res);
+}
+hdrmeta_buffer->pVtbl->Release(hdrmeta_buffer);
+}
+}
+
surface->pVtbl->SetPts(surface, frame->pts);
AMF_ASSIGN_PROPERTY_INT64(res, surface, PTS_PROP, frame->pts);
@@ -746,6 +817,18 @@ int ff_amf_receive_packet(AVCodecContext *avctx, AVPacket
*avpkt)
}
res_resubmit = AMF_OK;
if (ctx->delayed_surface != NULL) { // try to resubmit frame
+if (ctx->delayed_surface->pVtbl->HasProperty(ctx->delayed_surface,
L"av_frame_hdrmeta")) {
+AMFBuffer *
[FFmpeg-devel] [PATCH 10 bit support v5 1/3] avcodec/amfenc: Fixes the color information in the output.
From: Michael Fabian 'Xaymar' Dirks
added 10 bit support for amf hevc.
before:
command - ffmpeg.exe -hide_banner -y -hwaccel d3d11va -hwaccel_output_format
d3d11 -i test_10bit_file.mkv -an -c:v h264_amf res.dx11_hw_h264.mkv
output - Format of input frames context (p010le) is not supported by AMF.
command - ffmpeg.exe -hide_banner -y -hwaccel d3d11va -hwaccel_output_format
d3d11 -i test_10bit_file -an -c:v hevc_amf res.dx11_hw_hevc.mkv
output - Format of input frames context (p010le) is not supported by AMF.
after:
command - ffmpeg.exe -hide_banner -y -hwaccel d3d11va -hwaccel_output_format
d3d11 -i test_10bit_file -an -c:v h264_amf res.dx11_hw_h264.mkv
output - 10-bit input video is not supported by AMF H264 encoder
command - ffmpeg.exe -hide_banner -y -hwaccel d3d11va -hwaccel_output_format
d3d11 -i test_10bit_file -an -c:v hevc_amf res.dx11_hw_hevc.mkv
output - 10bit file
v2 - lost line returned in ff_amf_pix_fmts
v3 - fixes after review
v4 - extract duplicated code, fix incorrect processing of 10-bit input for h264
v5 - non-functional changes after review
Co-authored-by: Evgeny Pavlov
---
libavcodec/amfenc.c | 37 +
libavcodec/amfenc.h | 3 +++
libavcodec/amfenc_h264.c | 24
libavcodec/amfenc_hevc.c | 26 +-
4 files changed, 85 insertions(+), 5 deletions(-)
diff --git a/libavcodec/amfenc.c b/libavcodec/amfenc.c
index 061859f85c..0bd15dd812 100644
--- a/libavcodec/amfenc.c
+++ b/libavcodec/amfenc.c
@@ -60,6 +60,7 @@ const enum AVPixelFormat ff_amf_pix_fmts[] = {
#if CONFIG_DXVA2
AV_PIX_FMT_DXVA2_VLD,
#endif
+AV_PIX_FMT_P010,
AV_PIX_FMT_NONE
};
@@ -72,6 +73,7 @@ static const FormatMap format_map[] =
{
{ AV_PIX_FMT_NONE, AMF_SURFACE_UNKNOWN },
{ AV_PIX_FMT_NV12, AMF_SURFACE_NV12 },
+{ AV_PIX_FMT_P010, AMF_SURFACE_P010 },
{ AV_PIX_FMT_BGR0, AMF_SURFACE_BGRA },
{ AV_PIX_FMT_RGB0, AMF_SURFACE_RGBA },
{ AV_PIX_FMT_GRAY8, AMF_SURFACE_GRAY8 },
@@ -785,6 +787,41 @@ int ff_amf_receive_packet(AVCodecContext *avctx, AVPacket
*avpkt)
return ret;
}
+int ff_amf_get_color_profile(AVCodecContext *avctx)
+{
+amf_int64 color_profile = AMF_VIDEO_CONVERTER_COLOR_PROFILE_UNKNOWN;
+if (avctx->color_range == AVCOL_RANGE_JPEG) {
+/// Color Space for Full (JPEG) Range
+switch (avctx->colorspace) {
+case AVCOL_SPC_SMPTE170M:
+color_profile = AMF_VIDEO_CONVERTER_COLOR_PROFILE_FULL_601;
+break;
+case AVCOL_SPC_BT709:
+color_profile = AMF_VIDEO_CONVERTER_COLOR_PROFILE_FULL_709;
+break;
+case AVCOL_SPC_BT2020_NCL:
+case AVCOL_SPC_BT2020_CL:
+color_profile = AMF_VIDEO_CONVERTER_COLOR_PROFILE_FULL_2020;
+break;
+}
+} else {
+/// Color Space for Limited (MPEG) range
+switch (avctx->colorspace) {
+case AVCOL_SPC_SMPTE170M:
+color_profile = AMF_VIDEO_CONVERTER_COLOR_PROFILE_601;
+break;
+case AVCOL_SPC_BT709:
+color_profile = AMF_VIDEO_CONVERTER_COLOR_PROFILE_709;
+break;
+case AVCOL_SPC_BT2020_NCL:
+case AVCOL_SPC_BT2020_CL:
+color_profile = AMF_VIDEO_CONVERTER_COLOR_PROFILE_2020;
+break;
+}
+}
+return color_profile;
+}
+
const AVCodecHWConfigInternal *const ff_amfenc_hw_configs[] = {
#if CONFIG_D3D11VA
HW_CONFIG_ENCODER_FRAMES(D3D11, D3D11VA),
diff --git a/libavcodec/amfenc.h b/libavcodec/amfenc.h
index 2dbd378ef8..62736ef579 100644
--- a/libavcodec/amfenc.h
+++ b/libavcodec/amfenc.h
@@ -21,6 +21,7 @@
#include
+#include
#include
#include
#include
@@ -170,6 +171,8 @@ int ff_amf_receive_packet(AVCodecContext *avctx, AVPacket
*avpkt);
*/
extern const enum AVPixelFormat ff_amf_pix_fmts[];
+int ff_amf_get_color_profile(AVCodecContext *avctx);
+
/**
* Error handling helper
*/
diff --git a/libavcodec/amfenc_h264.c b/libavcodec/amfenc_h264.c
index bd544d12df..f785e091c9 100644
--- a/libavcodec/amfenc_h264.c
+++ b/libavcodec/amfenc_h264.c
@@ -199,6 +199,8 @@ static av_cold int amf_encode_init_h264(AVCodecContext
*avctx)
AMFRate framerate;
AMFSize framesize =
AMFConstructSize(avctx->width, avctx->height);
int deblocking_filter = (avctx->flags &
AV_CODEC_FLAG_LOOP_FILTER) ? 1 : 0;
+amf_int64color_profile;
+enum AVPixelFormat pix_fmt;
if (avctx->framerate.num > 0 && avctx->framerate.den > 0) {
framerate = AMFConstructRate(avctx->framerate.num,
avctx->framerate.den);
@@ -262,10 +264,24 @@ FF_ENABLE_DEPRECATION_WARNINGS
AMF_ASSIGN_PROPERTY_RATIO(res, ctx->encoder,
AMF_VIDEO_ENCODER_ASPECT_RATIO, ratio);
}
-/// Color Range (Partial/TV/MPEG or Full/PC/JPEG)
-
Re: [FFmpeg-devel] [RFC] financial sustainability Plan A (SPI)
On Tue, Oct 31, 2023 at 06:37:58PM +0100, Hendrik Leppkes wrote: > On Tue, Oct 31, 2023 at 6:31 PM Michael Niedermayer > wrote: > > > > On Tue, Oct 31, 2023 at 07:19:41PM +0200, Rémi Denis-Courmont wrote: > > > Le tiistaina 31. lokakuuta 2023, 18.58.57 EET Michael Niedermayer a écrit > > > : > > > > > That's not a credible solution for a library. All reverse dependency > > > > > developers would disable that before they ship affected FFmpeg > > > > > versions, > > > > > or worse, just stop updating their vendored FFmpeg. > > > > > > > > If its announced and we point to the commit, maybe half the minor users > > > > will remove it, maybe most of the bigger ones. If its not announced > > > > noone would remove it. companies do not audit the FFmpeg commits. > > > > They would remove it after seeing it but at that point it did what it > > > > intended to to, inform users again, like i said thats hypothetical and > > > > controversal. But basically doing the same as companies which put > > > > advertisements in without asking either creator nor viewer. > > > > > > How do you show ads without a GUI? Hijack the video signal from the > > > decoder? > > > > In this very very hypothetical idea ... > > it would not be a add, but a simple information box shown briefly that says > > something like "decoded with ffmpeg.org, donate if you enjoy" / "encoded > > with ffmpeg.org, donate if you enjoy" > > > > If as a professional user of a decoder library, it starts putting in > an ad or a watermark or whatever you want to call it, even if briefly, > i'm looking for a new decoder library, or will venture to remove the > message instantly. > And if that wasn't enough to completely destroy the projects > reputation, if you then try to hide it by randomizing or whatever, so > that testing before deployment doesn't see it, that definitely will. > > This is not acceptable behavior for a decoder. And no "exposure" due like i said, its a hypothetical and controversal thought experiment > to bad press will actually yield you a benefit. > Companies won't pay > you, because that doesn't get rid of the message. That misses the goal, the goal of this was to reach some of the more than 1 billion users we have and who do not know they are using FFmpeg. > They'll pay an > engineer to disable it. it would just show up once lets say on a specific day 1 year after the code is added. we would remove it on that day ourselfs. It would just be a simple one time shown message that says "Decoded by ffmpeg.org / Please donate, if you enjoy" thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Into a blind darkness they enter who follow after the Ignorance, they as if into a greater darkness enter who devote themselves to the Knowledge alone. -- Isha Upanishad 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] libavcodec/amfenc: Fix issue with missing headers in AV1 encoder
This is a trivial patch that fixes the bug. If there are no objections, I would like to merge it in 2-3 days ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] financial sustainability Plan A (SPI)
On Tue, Oct 31, 2023 at 6:31 PM Michael Niedermayer wrote: > > On Tue, Oct 31, 2023 at 07:19:41PM +0200, Rémi Denis-Courmont wrote: > > Le tiistaina 31. lokakuuta 2023, 18.58.57 EET Michael Niedermayer a écrit : > > > > That's not a credible solution for a library. All reverse dependency > > > > developers would disable that before they ship affected FFmpeg versions, > > > > or worse, just stop updating their vendored FFmpeg. > > > > > > If its announced and we point to the commit, maybe half the minor users > > > will remove it, maybe most of the bigger ones. If its not announced > > > noone would remove it. companies do not audit the FFmpeg commits. > > > They would remove it after seeing it but at that point it did what it > > > intended to to, inform users again, like i said thats hypothetical and > > > controversal. But basically doing the same as companies which put > > > advertisements in without asking either creator nor viewer. > > > > How do you show ads without a GUI? Hijack the video signal from the decoder? > > In this very very hypothetical idea ... > it would not be a add, but a simple information box shown briefly that says > something like "decoded with ffmpeg.org, donate if you enjoy" / "encoded with > ffmpeg.org, donate if you enjoy" > If as a professional user of a decoder library, it starts putting in an ad or a watermark or whatever you want to call it, even if briefly, i'm looking for a new decoder library, or will venture to remove the message instantly. And if that wasn't enough to completely destroy the projects reputation, if you then try to hide it by randomizing or whatever, so that testing before deployment doesn't see it, that definitely will. This is not acceptable behavior for a decoder. And no "exposure" due to bad press will actually yield you a benefit. Companies won't pay you, because that doesn't get rid of the message. They'll pay an engineer to disable it. - Hendrik ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] financial sustainability Plan A (SPI)
On Tue, Oct 31, 2023 at 07:19:41PM +0200, Rémi Denis-Courmont wrote: > Le tiistaina 31. lokakuuta 2023, 18.58.57 EET Michael Niedermayer a écrit : > > > That's not a credible solution for a library. All reverse dependency > > > developers would disable that before they ship affected FFmpeg versions, > > > or worse, just stop updating their vendored FFmpeg. > > > > If its announced and we point to the commit, maybe half the minor users > > will remove it, maybe most of the bigger ones. If its not announced > > noone would remove it. companies do not audit the FFmpeg commits. > > They would remove it after seeing it but at that point it did what it > > intended to to, inform users again, like i said thats hypothetical and > > controversal. But basically doing the same as companies which put > > advertisements in without asking either creator nor viewer. > > How do you show ads without a GUI? Hijack the video signal from the decoder? In this very very hypothetical idea ... it would not be a add, but a simple information box shown briefly that says something like "decoded with ffmpeg.org, donate if you enjoy" / "encoded with ffmpeg.org, donate if you enjoy" > Call a blocking MessageBox? Start the browser unsolicited? no, that would not work in many cases and is very intrusive > > In any case, you will only piss people off. And pissed off people are not > known > to give money. Rather they will look for another version of the affected app > or > another app to "fix" the "bug". its only shown once they dont have to do that. and for video streaming services they cannot replace the application as it would be server side. Also for these they are already full of advertisements noone will be offended by a few seconds shown box with 1-2 lines of text between several minute adds already. > > And anyhow, somebody would object to the TC, and I cannot believe that the TC > would then allow that sort of thing to be committed. > > But for the sake of the argument... its hypothetical only really, more or less to explore a thought experiment, see where it could lead and if anything can be learnt from it [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB If you drop bombs on a foreign country and kill a hundred thousand innocent people, expect your government to call the consequence "unprovoked inhuman terrorist attacks" and use it to justify dropping more bombs and killing more people. The technology changed, the idea is old. signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] financial sustainability Plan A (SPI)
Le tiistaina 31. lokakuuta 2023, 18.58.57 EET Michael Niedermayer a écrit : > > That's not a credible solution for a library. All reverse dependency > > developers would disable that before they ship affected FFmpeg versions, > > or worse, just stop updating their vendored FFmpeg. > > If its announced and we point to the commit, maybe half the minor users > will remove it, maybe most of the bigger ones. If its not announced > noone would remove it. companies do not audit the FFmpeg commits. > They would remove it after seeing it but at that point it did what it > intended to to, inform users again, like i said thats hypothetical and > controversal. But basically doing the same as companies which put > advertisements in without asking either creator nor viewer. How do you show ads without a GUI? Hijack the video signal from the decoder? Call a blocking MessageBox? Start the browser unsolicited? In any case, you will only piss people off. And pissed off people are not known to give money. Rather they will look for another version of the affected app or another app to "fix" the "bug". And anyhow, somebody would object to the TC, and I cannot believe that the TC would then allow that sort of thing to be committed. But for the sake of the argument... > Also dont ignore the effect of the controversy around this ;) That works both ways, unless you believe that "there is no such thing as bad press". > It would be on many news sites that XYZ displayed a notice > that it used FFmpeg and asked for donations for sustainability. Realistically, FFmpeg gets updated in reverse depencies application over periods of months, or even years. A few minor FFmpeg-based app letting this slip through would probably not be newsworthy. And it seems unlikely that major ones like Kodi, mpv, VLC, etc, would let this slip through in the first place. > All these news articles are free amplification of the message ;) That most probably will not happen, and if it does, it will most probably be in a bad way. This idea is a non-starter IMO. -- Rémi Denis-Courmont http://www.remlab.net/ ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] financial sustainability Plan A (SPI)
On Sun, Oct 29, 2023 at 09:36:13PM +0200, Rémi Denis-Courmont wrote: > Le sunnuntaina 29. lokakuuta 2023, 18.12.58 EET Michael Niedermayer a écrit : > > On Sun, Oct 29, 2023 at 04:35:35PM +0200, Rémi Denis-Courmont wrote: > > > Hi, > > > > > > Le 28 octobre 2023 21:01:57 GMT+03:00, Michael Niedermayer > a écrit : > > > >On Sat, Oct 28, 2023 at 07:21:03PM +0200, Michael Niedermayer wrote: > > > >> Hi ronald > > > >> > > > >> On Sat, Oct 28, 2023 at 12:43:15PM -0400, Ronald S. Bultje wrote: > > > >> > Hi Thilo, > > > >> > > > > >> > On Sat, Oct 28, 2023 at 11:31 AM Thilo Borgmann via ffmpeg-devel < > > > >> > > > > >> > ffmpeg-devel@ffmpeg.org> wrote: > > > >> > > What this is about, is to set up a way to properly spend the SPI > > > >> > > money > > > >> > > aside > > > >> > > from travel & hw. Why we should not do it because some companies > > > >> > > beurocracy, I > > > >> > > cannot see. > > > >> > > > > >> > I sincerely don't think the above description is what Kieran meant > > > >> > when he > > > >> > talked about sustainability at Demuxed, which this thread seems to be > > > >> > a > > > >> > response to. > > > >> > > > >> a quick reply here. I have not watched kierans presentation from > > > >> demuxed yet. So theres absolutly no chance anything i wrote till now > > > >> can be a respone to it. > > > > > > > >some more words about what the intend of this plan was, again not a > > > >respone > > > >to any presentation of anyone else > > > > > > > >Donations from people vs companies: both really. > > > > > > I think Ronald's point is that you need to pick one, and clarify which it > > > is, because as Ronald explained, it's unlikely that a *good* plan could > > > address both (conversely a plan that tries to address both is probably > > > poor and flawed). > > > > > > In other words, if you want to cover both cases, you need two separate > > > plans. > > you are correct, i agree here but this is a RFC so its not a final > > plan. > > > > i think for the donations from users the real question is how many > > of our users can we reach to explain them that they are using FFmpeg > > and a tiny donation would help us alot. > > if thats only a few thousand users then this will not work > > > > > And unfortunately, I do believe that Ronald is correct in pointing out > > > that big companies will want oversight in exchange for money. This is > > > very much counter to the current project setup, which (depending whom you > > > ask) is governed by the GA, or by Fabrice Bellard through his delegates. > > > > > > This is not to say that these corporate wishes should or should not be > > > accomodated. It is just an observation of those wishes. > > if i look at spi.txt, it says > > "SPI needs a contract in place which describes the work to be done. " > > > > so if we have someone do some payed development work be that one time or > > continous. There would be a contract that says what is going to be done. > > That also would have been approved by the community or GA or whatver and > > the company paying would have a say in whats in that contract, really > > limited by what we are ok with and what the law allows > > Unfortunately, that is missing the point. If a company wants to pay someone > for some specific tasks, they can already do that, with or without the > intervention of SPI. And they already know that they can do that, at least > without SPI. Your plan A is unnecessary for this case. If SPI has any benefit > here, it's maybe fiscal. > If there is really a tax benefit, you could emphasize > on the website and social networks tha SPI is available as an option. yes, thats a good idea > > Some companies could be willing to provide more sustainable funding for more > general maintenance, but they would probably require something like what > Ronald mentioned - especially for FFmpeg whose community has a poor > reputation. > > > > How do you plan to gain visibility from those billion users? Call me > > > pessimistic but this has been a known problem for 20+ years, and I have > > > yet to glimpse a credible solution. > > > It depends on the community. If the commuity wants to do it > > Just look at some online service which annoy you telling you to disable a > > add blocker we could detect a specific usecase we intend to target and > > print a simple message once that will not annoy the user a 2nd time > > This is very controversal and iam not sure if 99% are against it or find it > > funny. Iam just awnsering the "how it can be done" not saying iam in favor > > or against > > That's not a credible solution for a library. All reverse dependency > developers would disable that before they ship affected FFmpeg versions, or > worse, just stop updating their vendored FFmpeg. If its announced and we point to the commit, maybe half the minor users will remove it, maybe most of the bigger ones. If its not announced noone would remove it. companies do not audit the FFmpeg commits. They
Re: [FFmpeg-devel] [PATCH] Extract av_hls_codec_attr
> From: ffmpeg-devel On Behalf Of Romain > Beauxis > Sent: 2023年10月30日 9:06 > To: ffmpeg-devel@ffmpeg.org > Cc: Romain Beauxis > Subject: [FFmpeg-devel] [PATCH] Extract av_hls_codec_attr > > The logic for extracting HLS codec attribute strings is very useful and > can be re-used in many different situations when working with HLS > streams using libavcodec/libavformat. > > This patch extracts the function's code and places it into a publicly > available function. I don't think the implementation is complete enough to be exported as an API. And the ad-hoc API needs some design too. > > --- > libavcodec/Makefile | 2 + > libavcodec/hls.c | 105 +++ > libavcodec/hls.h | 42 + > libavformat/hlsenc.c | 83 +++--- > 4 files changed, 155 insertions(+), 77 deletions(-) > create mode 100644 libavcodec/hls.c > create mode 100644 libavcodec/hls.h > ___ 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 5/8] avfilter/vf_alphamerge: warn if input not full range
From: Niklas Haas
Alpha planes must always be full range, so complain loudly if fed
limited range grayscale input.
---
libavfilter/vf_alphamerge.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/libavfilter/vf_alphamerge.c b/libavfilter/vf_alphamerge.c
index 4bbc06da36..a5f5baf77e 100644
--- a/libavfilter/vf_alphamerge.c
+++ b/libavfilter/vf_alphamerge.c
@@ -60,6 +60,12 @@ static int do_alphamerge(FFFrameSync *fs)
if (!alpha_buf)
return ff_filter_frame(ctx->outputs[0], main_buf);
+if (alpha_buf->color_range == AVCOL_RANGE_MPEG) {
+av_log(ctx, AV_LOG_WARNING, "alpha plane color range tagged as %s, "
+ "output will be wrong!\n",
+ av_color_range_name(alpha_buf->color_range));
+}
+
if (s->is_packed_rgb) {
int x, y;
uint8_t *pin, *pout;
--
2.42.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v3 6/8] avfilter/vf_scale: simplify color matrix parsing logic
From: Niklas Haas
No need to write a custom string parser when we can just use an integer
option with preset values. The various bits of fallback logic are wholly
redundant with equivalent logic already inside sws_getCoefficients.
Note: I disallowed setting 'out_color_matrix=auto', because this does
not do anything meaningful in the current code (just hard-codes
AVCOL_SPC_BT470BG fallback).
---
libavfilter/vf_scale.c | 66 ++
1 file changed, 22 insertions(+), 44 deletions(-)
diff --git a/libavfilter/vf_scale.c b/libavfilter/vf_scale.c
index 23335cef4b..fb8e6a2b76 100644
--- a/libavfilter/vf_scale.c
+++ b/libavfilter/vf_scale.c
@@ -139,8 +139,8 @@ typedef struct ScaleContext {
char *flags_str;
-char *in_color_matrix;
-char *out_color_matrix;
+int in_color_matrix;
+int out_color_matrix;
int in_range;
int in_frame_range;
@@ -410,30 +410,6 @@ static int query_formats(AVFilterContext *ctx)
return 0;
}
-static const int *parse_yuv_type(const char *s, enum AVColorSpace colorspace)
-{
-if (!s)
-s = "bt601";
-
-if (s && strstr(s, "bt709")) {
-colorspace = AVCOL_SPC_BT709;
-} else if (s && strstr(s, "fcc")) {
-colorspace = AVCOL_SPC_FCC;
-} else if (s && strstr(s, "smpte240m")) {
-colorspace = AVCOL_SPC_SMPTE240M;
-} else if (s && (strstr(s, "bt601") || strstr(s, "bt470") || strstr(s,
"smpte170m"))) {
-colorspace = AVCOL_SPC_BT470BG;
-} else if (s && strstr(s, "bt2020")) {
-colorspace = AVCOL_SPC_BT2020_NCL;
-}
-
-if (colorspace < 1 || colorspace > 10 || colorspace == 8) {
-colorspace = AVCOL_SPC_BT470BG;
-}
-
-return sws_getCoefficients(colorspace);
-}
-
static int scale_eval_dimensions(AVFilterContext *ctx)
{
ScaleContext *scale = ctx->priv;
@@ -554,7 +530,7 @@ static int config_props(AVFilterLink *outlink)
scale->isws[0] = scale->isws[1] = scale->sws = NULL;
if (inlink0->w == outlink->w &&
inlink0->h == outlink->h &&
-!scale->out_color_matrix &&
+scale->out_color_matrix == AVCOL_SPC_UNSPECIFIED &&
scale->in_range == scale->out_range &&
inlink0->format == outlink->format)
;
@@ -840,8 +816,8 @@ scale:
in_range = in->color_range;
-if ( scale->in_color_matrix
-|| scale->out_color_matrix
+if ( scale->in_color_matrix != AVCOL_SPC_UNSPECIFIED
+|| scale->out_color_matrix != AVCOL_SPC_UNSPECIFIED
|| scale-> in_range != AVCOL_RANGE_UNSPECIFIED
|| in_range != AVCOL_RANGE_UNSPECIFIED
|| scale->out_range != AVCOL_RANGE_UNSPECIFIED) {
@@ -852,11 +828,13 @@ scale:
(int **), _full,
, , );
-if (scale->in_color_matrix)
-inv_table = parse_yuv_type(scale->in_color_matrix, in->colorspace);
-if (scale->out_color_matrix)
-table = parse_yuv_type(scale->out_color_matrix,
AVCOL_SPC_UNSPECIFIED);
-else if (scale->in_color_matrix)
+if (scale->in_color_matrix == -1 /* auto */)
+inv_table = sws_getCoefficients(in->colorspace);
+else if (scale->in_color_matrix != AVCOL_SPC_UNSPECIFIED)
+inv_table = sws_getCoefficients(scale->in_color_matrix);
+if (scale->out_color_matrix != AVCOL_SPC_UNSPECIFIED)
+table = sws_getCoefficients(scale->out_color_matrix);
+else if (scale->in_color_matrix != AVCOL_SPC_UNSPECIFIED)
table = inv_table;
if (scale-> in_range != AVCOL_RANGE_UNSPECIFIED)
@@ -1003,16 +981,16 @@ static const AVOption scale_options[] = {
{ "interl", "set interlacing", OFFSET(interlaced), AV_OPT_TYPE_BOOL, {.i64
= 0 }, -1, 1, FLAGS },
{ "size", "set video size", OFFSET(size_str),
AV_OPT_TYPE_STRING, {.str = NULL}, 0, FLAGS },
{ "s", "set video size", OFFSET(size_str),
AV_OPT_TYPE_STRING, {.str = NULL}, 0, FLAGS },
-{ "in_color_matrix", "set input YCbCr type", OFFSET(in_color_matrix),
AV_OPT_TYPE_STRING, { .str = "auto" }, .flags = FLAGS, "color" },
-{ "out_color_matrix", "set output YCbCr type", OFFSET(out_color_matrix),
AV_OPT_TYPE_STRING, { .str = NULL }, .flags = FLAGS, "color"},
-{ "auto",NULL, 0, AV_OPT_TYPE_CONST, { .str = "auto" },
0, 0, FLAGS, "color" },
-{ "bt601", NULL, 0, AV_OPT_TYPE_CONST, { .str = "bt601" },
0, 0, FLAGS, "color" },
-{ "bt470", NULL, 0, AV_OPT_TYPE_CONST, { .str = "bt470" },
0, 0, FLAGS, "color" },
-{ "smpte170m", NULL, 0, AV_OPT_TYPE_CONST, { .str = "smpte170m" },
0, 0, FLAGS, "color" },
-{ "bt709", NULL, 0, AV_OPT_TYPE_CONST, { .str = "bt709" },
0, 0, FLAGS, "color" },
-{ "fcc", NULL, 0, AV_OPT_TYPE_CONST, { .str = "fcc" },
0, 0, FLAGS, "color" },
-{ "smpte240m", NULL, 0, AV_OPT_TYPE_CONST, { .str =
[FFmpeg-devel] [PATCH v3 7/8] avfilter/vf_scale: tag output color space
From: Niklas Haas When using vf_scale to force a specific output color space, also tag this on the AVFrame. (Mirroring existing logic for output range) --- libavfilter/vf_scale.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/libavfilter/vf_scale.c b/libavfilter/vf_scale.c index fb8e6a2b76..3ec080693c 100644 --- a/libavfilter/vf_scale.c +++ b/libavfilter/vf_scale.c @@ -857,6 +857,9 @@ scale: brightness, contrast, saturation); out->color_range = out_full ? AVCOL_RANGE_JPEG : AVCOL_RANGE_MPEG; +if (scale->out_color_matrix >= 0 && +scale->out_color_matrix != AVCOL_SPC_UNSPECIFIED) +out->colorspace = scale->out_color_matrix; } av_reduce(>sample_aspect_ratio.num, >sample_aspect_ratio.den, -- 2.42.0 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v3 8/8] avcodec/pnm: explicitly tag color range
From: Niklas Haas
PGMYUV seems to be always limited range. This was a format originally
invented by FFmpeg at a time when YUVJ distinguished limited from full
range YUV, and this codec never appeared to output YUVJ in any
circumstance, so hard-coding limited range preserves the status quo.
The other formats are explicitly documented to be full range RGB/gray
formats. That said, don't tag them yet, due to outstanding bugs w.r.t
grayscale formats and color range handling.
This change in behavior updates a bunch of FATE tests in trivial ways
(added tagging being the only difference).
---
libavcodec/pnm.c | 7 --
tests/ref/lavf/mkv| 4 ++--
tests/ref/lavf/mkv_attachment | 4 ++--
tests/ref/lavf/mxf| 6 ++---
tests/ref/lavf/y4m| 4 ++--
tests/ref/seek/lavf-mkv | 44 +--
tests/ref/seek/lavf-y4m | 22 +-
7 files changed, 47 insertions(+), 44 deletions(-)
diff --git a/libavcodec/pnm.c b/libavcodec/pnm.c
index 77d24eeaf7..796807da23 100644
--- a/libavcodec/pnm.c
+++ b/libavcodec/pnm.c
@@ -97,10 +97,12 @@ int ff_pnm_decode_header(AVCodecContext *avctx, PNMContext
* const s)
} else if (s->type==1 || s->type==4) {
avctx->pix_fmt = AV_PIX_FMT_MONOWHITE;
} else if (s->type==2 || s->type==5) {
-if (avctx->codec_id == AV_CODEC_ID_PGMYUV)
+if (avctx->codec_id == AV_CODEC_ID_PGMYUV) {
avctx->pix_fmt = AV_PIX_FMT_YUV420P;
-else
+avctx->color_range = AVCOL_RANGE_MPEG;
+} else {
avctx->pix_fmt = AV_PIX_FMT_GRAY8;
+}
} else if (s->type==3 || s->type==6) {
avctx->pix_fmt = AV_PIX_FMT_RGB24;
} else if (s->type==7) {
@@ -240,5 +242,6 @@ int ff_pnm_decode_header(AVCodecContext *avctx, PNMContext
* const s)
h /= 3;
avctx->height = h;
}
+
return 0;
}
diff --git a/tests/ref/lavf/mkv b/tests/ref/lavf/mkv
index a8c3fd13e8..5a3c3b931e 100644
--- a/tests/ref/lavf/mkv
+++ b/tests/ref/lavf/mkv
@@ -1,3 +1,3 @@
-6224bc0893bd0bb8a789e74bbd38c9c7 *tests/data/lavf/lavf.mkv
-320440 tests/data/lavf/lavf.mkv
+dd709c2b5e173eaca39cdd4a10aac3ec *tests/data/lavf/lavf.mkv
+320447 tests/data/lavf/lavf.mkv
tests/data/lavf/lavf.mkv CRC=0xec6c3c68
diff --git a/tests/ref/lavf/mkv_attachment b/tests/ref/lavf/mkv_attachment
index 4c958af162..1a086a4f24 100644
--- a/tests/ref/lavf/mkv_attachment
+++ b/tests/ref/lavf/mkv_attachment
@@ -1,3 +1,3 @@
-05132b99d16128e552c1a6f1619be8b7 *tests/data/lavf/lavf.mkv_attachment
-472590 tests/data/lavf/lavf.mkv_attachment
+7cd7b06892b74d66da217c8dda90bfac *tests/data/lavf/lavf.mkv_attachment
+472597 tests/data/lavf/lavf.mkv_attachment
tests/data/lavf/lavf.mkv_attachment CRC=0xec6c3c68
diff --git a/tests/ref/lavf/mxf b/tests/ref/lavf/mxf
index fdd1ef5c9c..4cf3388afa 100644
--- a/tests/ref/lavf/mxf
+++ b/tests/ref/lavf/mxf
@@ -1,9 +1,9 @@
-9ec1ad83b3400de11ca2f70b3b2d4c4d *tests/data/lavf/lavf.mxf
+fac1fb467168a374e96ea1278869 *tests/data/lavf/lavf.mxf
526393 tests/data/lavf/lavf.mxf
tests/data/lavf/lavf.mxf CRC=0x8dddfaab
-3edfabe839a29f5902969c15ebac6d8d *tests/data/lavf/lavf.mxf
+d711481c4f81f6466fd92bdc7ed6c968 *tests/data/lavf/lavf.mxf
551481 tests/data/lavf/lavf.mxf
tests/data/lavf/lavf.mxf CRC=0xf091e687
-5bd0ce691510e6fae969886c32ad7a14 *tests/data/lavf/lavf.mxf
+7f4f8048c4f2d714e45947d4f39b8ea3 *tests/data/lavf/lavf.mxf
526393 tests/data/lavf/lavf.mxf
tests/data/lavf/lavf.mxf CRC=0x8dddfaab
diff --git a/tests/ref/lavf/y4m b/tests/ref/lavf/y4m
index 82c7087673..3c3fa830ad 100644
--- a/tests/ref/lavf/y4m
+++ b/tests/ref/lavf/y4m
@@ -1,3 +1,3 @@
-ec8178cb152f9cdbfd9cb724d977db2e *tests/data/lavf/lavf.y4m
-3801808 tests/data/lavf/lavf.y4m
+54f4ebcffedc886835444bb9d6aba3fb *tests/data/lavf/lavf.y4m
+3801828 tests/data/lavf/lavf.y4m
tests/data/lavf/lavf.y4m CRC=0x0a941f26
diff --git a/tests/ref/seek/lavf-mkv b/tests/ref/seek/lavf-mkv
index b8028dd075..e327959058 100644
--- a/tests/ref/seek/lavf-mkv
+++ b/tests/ref/seek/lavf-mkv
@@ -1,48 +1,48 @@
-ret: 0 st: 1 flags:1 dts:-0.011000 pts:-0.011000 pos:682 size:
208
+ret: 0 st: 1 flags:1 dts:-0.011000 pts:-0.011000 pos:689 size:
208
ret: 0 st:-1 flags:0 ts:-1.00
-ret: 0 st: 0 flags:1 dts: 0.00 pts: 0.00 pos:898 size:
27837
+ret: 0 st: 0 flags:1 dts: 0.00 pts: 0.00 pos:905 size:
27837
ret: 0 st:-1 flags:1 ts: 1.894167
-ret: 0 st: 0 flags:1 dts: 0.96 pts: 0.96 pos: 292314 size:
27834
+ret: 0 st: 0 flags:1 dts: 0.96 pts: 0.96 pos: 292321 size:
27834
ret: 0 st: 0 flags:0 ts: 0.788000
-ret: 0 st: 0 flags:1 dts: 0.96 pts: 0.96 pos: 292314 size:
27834
+ret: 0 st: 0 flags:1 dts: 0.96 pts: 0.96 pos: 292321 size:
27834
ret: 0 st: 0 flags:1 ts:-0.317000
-ret: 0 st: 0 flags:1 dts: 0.00 pts: 0.00 pos:898 size:
[FFmpeg-devel] [PATCH v3 4/8] avfilter/vf_extractplanes: tag alpha plane as full range
From: Niklas Haas
Alpha planes are explicitly full range, even for limited range YUVA
formats. Mark them as such.
---
libavfilter/vf_extractplanes.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/libavfilter/vf_extractplanes.c b/libavfilter/vf_extractplanes.c
index 7b7149ab24..ca406ff323 100644
--- a/libavfilter/vf_extractplanes.c
+++ b/libavfilter/vf_extractplanes.c
@@ -312,6 +312,8 @@ static int extract_plane(AVFilterLink *outlink, AVFrame
*frame)
if (!out)
return AVERROR(ENOMEM);
av_frame_copy_props(out, frame);
+if (idx == 3 /* alpha */)
+out->color_range = AVCOL_RANGE_JPEG;
if (s->is_packed) {
extract_from_packed(out->data[0], out->linesize[0],
--
2.42.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v3 2/8] swscale: don't omit ff_sws_init_range_convert for high-bit
From: Niklas Haas This was a complete hack seemingly designed to work around a different bug, which was fixed in the previous commit. As such, there is no more reason not to do this, as it simply breaks changing color range in sws_setColorspaceDetails for no reason. --- libswscale/utils.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/libswscale/utils.c b/libswscale/utils.c index 0a55657800..ec822ff5d9 100644 --- a/libswscale/utils.c +++ b/libswscale/utils.c @@ -1049,9 +1049,7 @@ int sws_setColorspaceDetails(struct SwsContext *c, const int inv_table[4], c->srcRange = srcRange; c->dstRange = dstRange; -//The srcBpc check is possibly wrong but we seem to lack a definitive reference to test this -//and what we have in ticket 2939 looks better with this check -if (need_reinit && (c->srcBpc == 8 || !isYUV(c->srcFormat))) +if (need_reinit) ff_sws_init_range_convert(c); c->dstFormatBpp = av_get_bits_per_pixel(desc_dst); -- 2.42.0 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v3 1/8] swscale: fix sws_setColorspaceDetails after sws_init_context
From: Niklas Haas
More commonly, this fixes the case of sws_setColorspaceDetails after
sws_getContext, since the latter implies sws_init_context.
The problem here is that sws_init_context sets up the range conversion
and fast path tables based on the values of srcRange/dstRange at init
time. This may result in locking in a "wrong" path (either using
unscaled fast path when range conversion later required, or using
scaled slow path when range conversion becomes no longer required).
There are two way outs:
1. Always initialize range conversion and unscaled converters, even if
they will be unused, and extend the runtime check.
2. Re-do initialization if the values change after
sws_setColorspaceDetails.
I opted for approach 1 because it was simpler and easier to reason
about.
Reword the av_log message to make it clear that this special converter
is not necessarily used, depending on whether or not there is range
conversion or YUV matrix conversion going on.
---
libswscale/swscale.c | 2 +-
libswscale/utils.c | 10 +++---
2 files changed, 4 insertions(+), 8 deletions(-)
diff --git a/libswscale/swscale.c b/libswscale/swscale.c
index 90e5b299ab..46ba68fe6a 100644
--- a/libswscale/swscale.c
+++ b/libswscale/swscale.c
@@ -1016,7 +1016,7 @@ static int scale_internal(SwsContext *c,
reset_ptr(src2, c->srcFormat);
reset_ptr((void*)dst2, c->dstFormat);
-if (c->convert_unscaled) {
+if (c->convert_unscaled && !c->lumConvertRange && !c->chrConvertRange) {
int offset = srcSliceY_internal;
int slice_h = srcSliceH;
diff --git a/libswscale/utils.c b/libswscale/utils.c
index e1ad685972..0a55657800 100644
--- a/libswscale/utils.c
+++ b/libswscale/utils.c
@@ -1715,30 +1715,26 @@ static av_cold int sws_init_single_context(SwsContext
*c, SwsFilter *srcFilter,
if (unscaled && !usesHFilter && !usesVFilter &&
c->alphablend != SWS_ALPHA_BLEND_NONE &&
isALPHA(srcFormat) &&
-(c->srcRange == c->dstRange || isAnyRGB(dstFormat)) &&
alphaless_fmt(srcFormat) == dstFormat
) {
c->convert_unscaled = ff_sws_alphablendaway;
if (flags & SWS_PRINT_INFO)
av_log(c, AV_LOG_INFO,
-"using alpha blendaway %s -> %s special converter\n",
+"alpha blendaway %s -> %s special converter is
available\n",
av_get_pix_fmt_name(srcFormat),
av_get_pix_fmt_name(dstFormat));
return 0;
}
/* unscaled special cases */
-if (unscaled && !usesHFilter && !usesVFilter &&
-(c->srcRange == c->dstRange || isAnyRGB(dstFormat) ||
- isFloat(srcFormat) || isFloat(dstFormat))){
+if (unscaled && !usesHFilter && !usesVFilter) {
ff_get_unscaled_swscale(c);
if (c->convert_unscaled) {
if (flags & SWS_PRINT_INFO)
av_log(c, AV_LOG_INFO,
- "using unscaled %s -> %s special converter\n",
+ "unscaled %s -> %s special converter is available\n",
av_get_pix_fmt_name(srcFormat),
av_get_pix_fmt_name(dstFormat));
-return 0;
}
}
--
2.42.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v3 3/8] swscale/yuv2rgb: fix sws_getCoefficients for colorspace=0
From: Niklas Haas
The documentation states that invalid entries default to SWS_CS_DEFAULT.
A value of 0 is not a valid SWS_CS_*, yet the code incorrectly
hard-codes it to BT.709 coefficients instead of SWS_CS_DEFAULT.
---
libswscale/yuv2rgb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libswscale/yuv2rgb.c b/libswscale/yuv2rgb.c
index 9c3f5e23c6..0a84b662f9 100644
--- a/libswscale/yuv2rgb.c
+++ b/libswscale/yuv2rgb.c
@@ -46,7 +46,7 @@
* where Y = cr * R + cg * G + cb * B and cr + cg + cb = 1.
*/
const int32_t ff_yuv2rgb_coeffs[11][4] = {
-{ 117489, 138438, 13975, 34925 }, /* no sequence_display_extension */
+{ 104597, 132201, 25675, 53279 }, /* no sequence_display_extension */
{ 117489, 138438, 13975, 34925 }, /* ITU-R Rec. 709 (1990) */
{ 104597, 132201, 25675, 53279 }, /* unspecified */
{ 104597, 132201, 25675, 53279 }, /* reserved */
--
2.42.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] Extract av_hls_codec_attr
On Sun, Oct 29, 2023 at 08:05:50PM -0500, Romain Beauxis wrote: > The logic for extracting HLS codec attribute strings is very useful and > can be re-used in many different situations when working with HLS > streams using libavcodec/libavformat. > > This patch extracts the function's code and places it into a publicly > available function. > > --- > libavcodec/Makefile | 2 + > libavcodec/hls.c | 105 +++ > libavcodec/hls.h | 42 + > libavformat/hlsenc.c | 83 +++--- you cannot call ff_* functions across libs they need to start with av* / avpriv* [...] > + rbsp_buf = ff_nal_unit_extract_rbsp(data, remain_size, > _size, 0); libavcodec/libavcodec.so: undefined reference to `ff_nal_unit_extract_rbsp' clang: error: linker command failed with exit code 1 (use -v to see invocation) Makefile:133: recipe for target 'ffmpeg_g' failed make: *** [ffmpeg_g] Error 1 make: *** Waiting for unfinished jobs libavcodec/libavcodec.so: undefined reference to `ff_nal_unit_extract_rbsp' clang: error: linker command failed with exit code 1 (use -v to see invocation) Makefile:133: recipe for target 'ffplay_g' failed make: *** [ffplay_g] Error 1 thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB If a bugfix only changes things apparently unrelated to the bug with no further explanation, that is a good sign that the bugfix is 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] [PATCH v2 06/10] avfilter/vf_scale: properly respect to input colorimetry
On Sat, 28 Oct 2023 16:41:13 +0200 Niklas Haas wrote:
> From: Niklas Haas
>
> This code, as written, skips sws_init_context if scale->in_range was not
> set, even if scale->in_frame_range is set to something. So this would
> hit the 'no sws context' fast path in scale_frame and skip color range
> conversion even where technically required. This had the effect of, in
> practice, effectively applying limited/full range conversion if and only
> if you set e.g. a nonzero yuv color matrix, which is obviously
> undesirable behavior.
>
> Second, the assignment of out->color_range inside the branch would fail
> to properly propagate tags for any actually applied conversion, for
> example on conversion to a forced full range format.
>
> Solve both of these problems and make the code much easier to understand
> and follow by doing the following:
>
> 1. Always initialize sws context on get_props
> 2. Always use sws_getColorspaceDetails + sws_setColorspaceDetails to
>fix the conversion matrices per-frame.
> 3. Rather than testing if the context exists, do the no-op test after
>settling the above values and deciding what conversion to actually
>perform.
> ---
> libavfilter/vf_scale.c | 186 +
> 1 file changed, 76 insertions(+), 110 deletions(-)
>
> diff --git a/libavfilter/vf_scale.c b/libavfilter/vf_scale.c
> index 23335cef4b..3d58de0494 100644
> --- a/libavfilter/vf_scale.c
> +++ b/libavfilter/vf_scale.c
> @@ -143,7 +143,6 @@ typedef struct ScaleContext {
> char *out_color_matrix;
>
> int in_range;
> -int in_frame_range;
> int out_range;
>
> int out_h_chr_pos;
> @@ -356,8 +355,6 @@ static av_cold int init(AVFilterContext *ctx)
> if (!threads)
> av_opt_set_int(scale->sws_opts, "threads",
> ff_filter_get_nb_threads(ctx), 0);
>
> -scale->in_frame_range = AVCOL_RANGE_UNSPECIFIED;
> -
> return 0;
> }
>
> @@ -520,6 +517,7 @@ static int config_props(AVFilterLink *outlink)
> const AVPixFmtDescriptor *desc = av_pix_fmt_desc_get(inlink->format);
> const AVPixFmtDescriptor *outdesc = av_pix_fmt_desc_get(outfmt);
> ScaleContext *scale = ctx->priv;
> +struct SwsContext **swscs[3] = {>sws, >isws[0],
> >isws[1]};
> uint8_t *flags_val = NULL;
> int ret;
>
> @@ -552,65 +550,46 @@ static int config_props(AVFilterLink *outlink)
> if (scale->isws[1])
> sws_freeContext(scale->isws[1]);
> scale->isws[0] = scale->isws[1] = scale->sws = NULL;
> -if (inlink0->w == outlink->w &&
> -inlink0->h == outlink->h &&
> -!scale->out_color_matrix &&
> -scale->in_range == scale->out_range &&
> -inlink0->format == outlink->format)
> -;
> -else {
> -struct SwsContext **swscs[3] = {>sws, >isws[0],
> >isws[1]};
> -int i;
> -
> -for (i = 0; i < 3; i++) {
> -int in_v_chr_pos = scale->in_v_chr_pos, out_v_chr_pos =
> scale->out_v_chr_pos;
> -struct SwsContext *const s = sws_alloc_context();
> -if (!s)
> -return AVERROR(ENOMEM);
> -*swscs[i] = s;
> -
> -ret = av_opt_copy(s, scale->sws_opts);
> -if (ret < 0)
> -return ret;
>
> -av_opt_set_int(s, "srcw", inlink0 ->w, 0);
> -av_opt_set_int(s, "srch", inlink0 ->h >> !!i, 0);
> -av_opt_set_int(s, "src_format", inlink0->format, 0);
> -av_opt_set_int(s, "dstw", outlink->w, 0);
> -av_opt_set_int(s, "dsth", outlink->h >> !!i, 0);
> -av_opt_set_int(s, "dst_format", outfmt, 0);
> -if (scale->in_range != AVCOL_RANGE_UNSPECIFIED)
> -av_opt_set_int(s, "src_range",
> - scale->in_range == AVCOL_RANGE_JPEG, 0);
> -else if (scale->in_frame_range != AVCOL_RANGE_UNSPECIFIED)
> -av_opt_set_int(s, "src_range",
> - scale->in_frame_range == AVCOL_RANGE_JPEG, 0);
> -if (scale->out_range != AVCOL_RANGE_UNSPECIFIED)
> -av_opt_set_int(s, "dst_range",
> - scale->out_range == AVCOL_RANGE_JPEG, 0);
> -
> -/* Override chroma location default settings to have the correct
> - * chroma positions. MPEG chroma positions are used by
> convention.
> - * Note that this works for both MPEG-1/JPEG and MPEG-2/4 chroma
> - * locations, since they share a vertical alignment */
> -if (desc->log2_chroma_h == 1 && scale->in_v_chr_pos == -513) {
> -in_v_chr_pos = (i == 0) ? 128 : (i == 1) ? 64 : 192;
> -}
> -
> -if (outdesc->log2_chroma_h == 1 && scale->out_v_chr_pos == -513)
> {
> -out_v_chr_pos = (i == 0) ? 128 : (i == 1) ? 64 : 192;
> -}
> -
> -av_opt_set_int(s, "src_h_chr_pos", scale->in_h_chr_pos, 0);
> -
Re: [FFmpeg-devel] [PATCH 1/4] lavc/aarch64: new optimization for 8-bit hevc_epel_v
On Thu, 26 Oct 2023, Logan.Lyu wrote:
And I missed submitting a commit that was earlier than these four commits,
which caused the corrupted whitespace problem. Now I have recreated these
patches.
In addition, I rebased it to ensure that these patches can be successfully
applied on the latest master branch.
Please check again, thank you.
Thanks, now these was possibly to apply, and they looked mostly ok, so I
touched up the last details I noticed and pushed them.
Things I noticed and fixed before pushing:
A bunch of minor cosmetics, you had minor misindentations in a few places
(that were copypasted around in lots of places), that I fixed like this:
ld1 {v18.16b}, [x1], x2
.macro calc src0, src1, src2, src3
-ld1{\src3\().16b}, [x1], x2
+ld1 {\src3\().16b}, [x1], x2
moviv4.8h, #0
moviv5.8h, #0
calc_epelb v4, \src0, \src1, \src2, \src3
@@ -461,7 +461,7 @@ function ff_hevc_put_hevc_epel_v64_8_neon, export=1
.endm
1: calc_all16
.purgem calc
-2: ld1 {v8.8b-v11.8b}, [sp]
+2: ld1 {v8.8b-v11.8b}, [sp]
add sp, sp, #32
ret
The first patch, with mostly small trivial functions, can probably be
scheduled better for in-order cores. I'll send a patch if I can make them
measurably faster.
In almost every patch, you have loads/stores to the stack; you use the
fused stack decrement nicely everywhere possible, but for the loading,
you're almost always lacking the fused stack increment. I've fixed it now
for this patchset, but please do keep this in mind and fix it up before
submitting any further patches. I've fixed that up like this:
bl X(ff_hevc_put_hevc_epel_h4_8_neon_i8mm)
-ldp x5, x30, [sp]
ldp x0, x3, [sp, #16]
-add sp, sp, #32
+ldp x5, x30, [sp], #32
load_epel_filterh x5, x4
(In many places.)
In one place, you wrote below the stack pointer before decrementing it.
That's ok on OSes with a defined red zone, but we shouldn't need to assume
that; I've fixed that like this:
function ff_hevc_put_hevc_qpel_v48_8_neon, export=1
-stp x5, x30, [sp, #-16]
-stp x0, x1, [sp, #-32]
stp x2, x3, [sp, #-48]!
+stp x0, x1, [sp, #16]
+stp x5, x30, [sp, #32]
I'll push the patchset with these changes soon.
// Martin
___
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 07/10] avfilter/vf_scale: preserve YUV range by default
On Tue, 31 Oct 2023 00:42:47 +0100 Michael Niedermayer wrote: > On Sat, Oct 28, 2023 at 04:41:14PM +0200, Niklas Haas wrote: > > From: Niklas Haas > > > > YUV->YUV conversions should preserve input range, if the output range is > > unspecified. Ensures full-range YUV input comes out as full-range YUV > > output by default, even through YUV->YUV pixel format conversions. > > --- > > libavfilter/vf_scale.c | 23 +++ > > 1 file changed, 23 insertions(+) > > this seems to change the output of the following: > ffmpeg -i 4493/AVCI100.mov -vframes 3 -bitexact file.nut > did not investigate if this is a bug or bugfix > > files are here: https://samples.ffmpeg.org/ffmpeg-bugs/trac/ticket524/ Seems like it's a regression. mpeg4 does not support full range YUV, so giving it full range YUV causes wrong levels to be saved. I will drop this commit from this series and include it as part of the filter negotiation series, since that one has the necessary infrastructure to handle this more gracefully. ___ 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] avfillter/buffersrc: activate and EOF fix
Paul B Mahol (12023-10-27): > Both patches are required to fix out of memory scenario with this use case: I checked. The OOM still happens with these two patches => they do not fix the issue => rejected. > This was a test. That you failed. Are you sure you are mature enough to go on the Internet unsupervised? -- 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] [PATCH 2/2] configure: Improve aarch64 feature detection on older, broken Clang versions
On Tue, 24 Oct 2023, Martin Storsjö wrote: Clang versions before 17 (Xcode versions up to and including 15.0) had a very annoying bug in its behaviour of the ".arch" directive in assembly. If the directive only contained a level, such as ".arch armv8.2-a", it did validate the name of the level, but it didn't apply the level to what instructions are allowed. The level was applied if the directive contained an extra feature enabled, such as ".arch armv8.2-a+crc" though. It was also applied on the next ".arch_extension" directive. This bug, combined with the fact that the same versions of Clang didn't support the dotprod/i8mm extension names in either ".arch +" or in ".arch_extension", could lead to unexepcted build failures. As the dotprod/i8mm extensions couldn't be enabled dynamically via the ".arch_extension" directive, someone building ffmpeg could try to enable them by configuring their build with --extra-cflags="-march=armv8.6-a". During configure, we test for support for the i8mm instructions like this: # Built with -march=armv8.6-a .arch armv8.2-a # Has no visible effect here #.arch_extension i8mm # Omitted as the extension name isn't known usdot v0.4s, v0.16b, v0.16b # Successfully assembled as armv8.6-a is the effective level, # and i8mm is enabled implicitly in armv8.6-a. Thus, we would enable assembling those instructions. However if we later check for another extension, such as sve (which those versions of Clang actually do support), we can later run into the following situation when building actual code: # Built with -march=armv8.6-a .arch armv8.2-a # Has no visible effect here #.arch_extension i8mm # Omitted as the extension name isn't known .arch_extension sve # Included as "sve" is as supported extension name # .arch_extension effectively activates the previous .arch directive, # so the effective level is armv8.2-a+sve now. usdot v0.4s, v0.16b, v0.16b # Fails to build the instructions that require i8mm. Despite the # configure check, the unrelated ".arch_extension sve" directive # breaks the functionality of the i8mm feature. This patch avoids this situation: - By adding a dummy feature such as "+crc" on the .arch directive (if supported), we make sure that it does get applied immediately, avoiding it taking effect spuriously at a later unrelated ".arch_extension" directive. - By checking for higher arch levels such as armv8.4-a and armv8.6-a, we can assemble the dotprod and i8mm extensions without the user needing to pass -march=armv8.6-a. This allows using the dotprod/i8mm codepaths via runtime detection while keeping the binary runnable on older versions. I.e. this enables the i8mm codepaths on Apple M2 machines while built with Xcode's Clang. TL;DR: Enable the I8MM extensions for Apple M2 without the user needing to do a custom configuration; avoid potential build breakage if a user does such a custom configuration. Once Xcode versions that have these issues fixed are prevalent, we can consider reverting this change. --- configure | 21 - 1 file changed, 20 insertions(+), 1 deletion(-) Will push now. // Martin ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/2] aarch64: Simplify the linux runtime cpu detection code
On Tue, 24 Oct 2023, Sean McGovern wrote:
On Tue, Oct 24, 2023, 08:23 Martin Storsjö wrote:
Skip doing the whole getauxval(AT_HWCAP) if HWCAP_CPUID isn't
defined.
---
libavutil/aarch64/cpu.c | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/libavutil/aarch64/cpu.c b/libavutil/aarch64/cpu.c
index bd780e8591..2b50c426bc 100644
--- a/libavutil/aarch64/cpu.c
+++ b/libavutil/aarch64/cpu.c
@@ -30,11 +30,9 @@
static int detect_flags(void)
{
int flags = 0;
-unsigned long hwcap;
-
-hwcap = getauxval(AT_HWCAP);
#if defined(HWCAP_CPUID)
+unsigned long hwcap = getauxval(AT_HWCAP);
// We can check for DOTPROD and I8MM using HWCAP_ASIMDDP and
// HWCAP2_I8MM too, avoiding to read the CPUID registers (which
triggers
// a trap, handled by the kernel). However the HWCAP_* defines for
these
@@ -53,8 +51,6 @@ static int detect_flags(void)
if (((tmp >> 52) & 0xf) == 0x1)
flags |= AV_CPU_FLAG_I8MM;
}
-#else
-(void)hwcap;
#endif
return flags;
--
2.34.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Good call, and LGTM.
Thanks, will push now.
// Martin
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v5] fftools/ffplay: add hwaccel decoding support
> 在 2023年10月31日，下午4:40，Zhao Zhili 写道： > > >> >> On Oct 31, 2023, at 13:16, Lynne wrote: >> >> Oct 30, 2023, 18:35 by quinkbl...@foxmail.com: >> >>> On 2023/10/31 01:05, Lynne wrote: >>> Oct 30, 2023, 17:05 by quinkbl...@foxmail.com: > From: Zhao Zhili > > Add vulkan renderer via libplacebo. > > Simple usage: > $ ffplay -hwaccel vulkan foo.mp4 > > Use cuda to vulkan map: > $ ffplay -hwaccel cuda foo.mp4 > > Create vulkan instance by libplacebo, and enable debug: > $ ffplay -hwaccel vulkan \ > -vulkan_params create_by_placebo=1:debug=1 foo.mp4 > --- > v5: > 1. add vulkan_params option. > 2. vulkan instance can be create by hwcontext or libplacebo. > > v4: add more optional extensions > v3: shared vulkan instance between libplacebo and hwcontext > You did it the other way. Instead of creating a device through libplacebo, just create a Vulkan device via the hwcontext, and use it for libplacebo. >>> >>> I have done both: >>> >>> 1. create vulkan device by hwcontext and import to placebo >>> >>> 2. create vulkan device by placebo and pass to hwcontext >>> >>> It's controlled by -vulkan_params create_by_placebo=1(0). Default is the >>> first behavior. I mean default is create_by_placebo=0. >>> >>> Did I miss something? >>> >> >> Thanks, I overlooked that. Is there a reason for having a setting, and >> having that as the default? > > There is no particular reason for which one be the default. Let hwcontext > create vulkan > device is easy, but the code path has been tested by fftools/ffmpeg. The > second choice > covers another code path (av_hwdevice_ctx_alloc + av_hwdevice_ctx_init) and > helps > finding bugs. > > The macOS compatibility issue was found by the first choice. The memleak > issue was found by > the second. > >> ___ >> 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". ___ 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/mpegvideo: Remove spec-incompliant inverse quantisation
On Mon, Oct 30, 2023 at 02:11:27PM +0100, Andreas Rheinhardt wrote: > Section 7.4.4 of the MPEG-2 specifications requires that the > last bit of the last coefficient be toggled so that the sum > of all coefficients is odd; both our decoder and encoder > did this only if the bitexact flag has been set (although > stuff like this should be behind AV_CODEC_FLAG2_FAST). > This patch changes this by removing the spec-incompliant > functions. This commit message should include benchamarks documenting the speed loss (of the unquantize, the IDCT and overall) It is expected that the speed of some IDCTs will be impacted negativly as the non zero terms will prevent the skiping of some significant code as well as information about how much PSNR improves (to the encoder input) Also the change is a +-1 in one spot before the IDCT, the IDCT is not bitexactly specified in MPEG-2 so one could think of this as a correct implementation followed by a IDCT that was sometimes +-1 off instead of spec non compliance Only after the benchmarks and PSNR is presented should we decide if this is a change we want thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB No great genius has ever existed without some touch of madness. -- Aristotle signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v5] fftools/ffplay: add hwaccel decoding support
> On Oct 31, 2023, at 13:16, Lynne wrote: > > Oct 30, 2023, 18:35 by quinkbl...@foxmail.com: > >> >> On 2023/10/31 01:05, Lynne wrote: >> >>> Oct 30, 2023, 17:05 by quinkbl...@foxmail.com: >>> From: Zhao Zhili Add vulkan renderer via libplacebo. Simple usage: $ ffplay -hwaccel vulkan foo.mp4 Use cuda to vulkan map: $ ffplay -hwaccel cuda foo.mp4 Create vulkan instance by libplacebo, and enable debug: $ ffplay -hwaccel vulkan \ -vulkan_params create_by_placebo=1:debug=1 foo.mp4 --- v5: 1. add vulkan_params option. 2. vulkan instance can be create by hwcontext or libplacebo. v4: add more optional extensions v3: shared vulkan instance between libplacebo and hwcontext >>> You did it the other way. Instead of creating a device through libplacebo, >>> just create a Vulkan device via the hwcontext, and use it for libplacebo. >>> >> >> I have done both: >> >> 1. create vulkan device by hwcontext and import to placebo >> >> 2. create vulkan device by placebo and pass to hwcontext >> >> It's controlled by -vulkan_params create_by_placebo=1(0). Default is the >> first behavior. >> >> Did I miss something? >> > > Thanks, I overlooked that. Is there a reason for having a setting, and having > that as the default? There is no particular reason for which one be the default. Let hwcontext create vulkan device is easy, but the code path has been tested by fftools/ffmpeg. The second choice covers another code path (av_hwdevice_ctx_alloc + av_hwdevice_ctx_init) and helps finding bugs. The macOS compatibility issue was found by the first choice. The memleak issue was found by the second. > ___ > 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".
