[FFmpeg-devel] [PATCH] lavfi/qsv: Copy metadata fields from the given input
From: Haihao Xiang
Currently it always copies the metadata fields from the last input when
there are multiple inputs for the filter. For example, the metadata
fields from input1 are copied to the output for overlay_qsv filter,
however for regular overlay filters, the metadata fields from input0 are
copied to the output. With this fix, we may copy the metadata fields
from input0 to the ouput as well.
Signed-off-by: Haihao Xiang
---
libavfilter/qsvvpp.c | 29 +++--
libavfilter/qsvvpp.h | 2 +-
libavfilter/vf_overlay_qsv.c | 9 ++---
libavfilter/vf_stack_qsv.c | 9 ++---
libavfilter/vf_vpp_qsv.c | 2 +-
5 files changed, 25 insertions(+), 26 deletions(-)
diff --git a/libavfilter/qsvvpp.c b/libavfilter/qsvvpp.c
index 8c92fec0c1..10d970652e 100644
--- a/libavfilter/qsvvpp.c
+++ b/libavfilter/qsvvpp.c
@@ -441,11 +441,6 @@ static QSVFrame *submit_frame(QSVVPPContext *s,
AVFilterLink *inlink, AVFrame *p
av_frame_free(_frame->frame);
return NULL;
}
-
-if (av_frame_copy_props(qsv_frame->frame, picref) < 0) {
-av_frame_free(_frame->frame);
-return NULL;
-}
} else
qsv_frame->frame = av_frame_clone(picref);
@@ -494,12 +489,6 @@ static QSVFrame *query_frame(QSVVPPContext *s,
AVFilterLink *outlink, const AVFr
if (!out_frame->frame)
return NULL;
-ret = av_frame_copy_props(out_frame->frame, in);
-if (ret < 0) {
-av_log(ctx, AV_LOG_ERROR, "Failed to copy metadata fields from src
to dst.\n");
-return NULL;
-}
-
ret = av_hwframe_get_buffer(outlink->hw_frames_ctx, out_frame->frame,
0);
if (ret < 0) {
av_log(ctx, AV_LOG_ERROR, "Can't allocate a surface.\n");
@@ -516,12 +505,6 @@ static QSVFrame *query_frame(QSVVPPContext *s,
AVFilterLink *outlink, const AVFr
if (!out_frame->frame)
return NULL;
-ret = av_frame_copy_props(out_frame->frame, in);
-if (ret < 0) {
-av_log(ctx, AV_LOG_ERROR, "Failed to copy metadata fields from src
to dst.\n");
-return NULL;
-}
-
ret = map_frame_to_surface(out_frame->frame,
_frame->surface);
if (ret < 0)
@@ -958,7 +941,7 @@ int ff_qsvvpp_close(AVFilterContext *avctx)
return 0;
}
-int ff_qsvvpp_filter_frame(QSVVPPContext *s, AVFilterLink *inlink, AVFrame
*picref)
+int ff_qsvvpp_filter_frame(QSVVPPContext *s, AVFilterLink *inlink, AVFrame
*picref, AVFrame *propref)
{
AVFilterContext *ctx = inlink->dst;
AVFilterLink *outlink = ctx->outputs[0];
@@ -1015,6 +998,16 @@ int ff_qsvvpp_filter_frame(QSVVPPContext *s, AVFilterLink
*inlink, AVFrame *picr
return AVERROR(EAGAIN);
break;
}
+
+if (propref) {
+ret1 = av_frame_copy_props(out_frame->frame, propref);
+if (ret1 < 0) {
+av_frame_free(_frame->frame);
+av_log(ctx, AV_LOG_ERROR, "Failed to copy metadata fields from
src to dst.\n");
+return ret1;
+}
+}
+
out_frame->frame->pts = av_rescale_q(out_frame->surface.Data.TimeStamp,
default_tb, outlink->time_base);
diff --git a/libavfilter/qsvvpp.h b/libavfilter/qsvvpp.h
index 4eea7a46c7..3b9192b62e 100644
--- a/libavfilter/qsvvpp.h
+++ b/libavfilter/qsvvpp.h
@@ -131,7 +131,7 @@ int ff_qsvvpp_init(AVFilterContext *avctx, QSVVPPParam
*param);
int ff_qsvvpp_close(AVFilterContext *avctx);
/* vpp filter frame and call the cb if needed */
-int ff_qsvvpp_filter_frame(QSVVPPContext *vpp, AVFilterLink *inlink, AVFrame
*frame);
+int ff_qsvvpp_filter_frame(QSVVPPContext *vpp, AVFilterLink *inlink, AVFrame
*frame, AVFrame *propref);
int ff_qsvvpp_print_iopattern(void *log_ctx, int mfx_iopattern,
const char *extra_string);
diff --git a/libavfilter/vf_overlay_qsv.c b/libavfilter/vf_overlay_qsv.c
index 0f52c93245..059602fe03 100644
--- a/libavfilter/vf_overlay_qsv.c
+++ b/libavfilter/vf_overlay_qsv.c
@@ -228,13 +228,16 @@ static int process_frame(FFFrameSync *fs)
{
AVFilterContext *ctx = fs->parent;
QSVVPPContext*qsv = fs->opaque;
-AVFrame*frame = NULL;
+AVFrame*frame = NULL, *propref = NULL;
int ret = 0, i;
for (i = 0; i < ctx->nb_inputs; i++) {
ret = ff_framesync_get_frame(fs, i, , 0);
-if (ret == 0)
-ret = ff_qsvvpp_filter_frame(qsv, ctx->inputs[i], frame);
+if (ret == 0) {
+if (i == 0)
+propref = frame;
+ret = ff_qsvvpp_filter_frame(qsv, ctx->inputs[i], frame, propref);
+}
if (ret < 0 && ret != AVERROR(EAGAIN))
break;
}
diff --git a/libavfilter/vf_stack_qsv.c
Re: [FFmpeg-devel] [PATCH v2] avcodec/jpeg2000dec: support of 2 fields in 1 AVPacket
On Wed, Apr 24, 2024 at 01:20:02PM +0200, Jerome Martinez wrote: > Hi, I'm bumping this patch proposal for avoiding a situation where FFmpeg > skips half the visual content when 2 jpeg2000 codestreams are present in one > frame. I re-reviewed this discussion and think I answered all concerns. I'm > hesitant with patch v3 because I consider that touching frame_worker_thread > for this feature is not so useful but I am ok with either patch v2 or v3. > Thanks much, > Jérôme I hope i applied the correct patch: libavcodec/avcodec.h | 14 ++ libavcodec/codec_par.c | 3 +++ libavcodec/codec_par.h | 5 + libavcodec/decode.c| 3 +++ libavcodec/defs.h | 7 +++ libavcodec/jpeg2000dec.c | 73 +++-- libavcodec/jpeg2000dec.h | 6 ++ libavcodec/pthread_frame.c | 3 +++ libavformat/mxfdec.c | 14 ++ 9 files changed, 118 insertions(+), 10 deletions(-) but that with: ./ffmpeg -i ~/tickets/1102/ntsc2.mxf -bitexact -vframes 1 /tmp/file.bmp segafaults: ==1031087== Invalid write of size 2 ==1031087==at 0x9D758F: jpeg2000_decode_tile (in ffmpeg/ffmpeg_g) ==1031087==by 0x7C3820: avcodec_default_execute2 (in ffmpeg/ffmpeg_g) ==1031087==by 0x9DCE6E: jpeg2000_decode_frame (in ffmpeg/ffmpeg_g) ==1031087==by 0xAF912F: frame_worker_thread (in ffmpeg/ffmpeg_g) ==1031087==by 0x4A00608: start_thread (pthread_create.c:477) ==1031087==by 0x8104352: clone (clone.S:95) ==1031087== Address 0x0 is not stack'd, malloc'd or (recently) free'd [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB While the State exists there can be no freedom; when there is freedom there will be no State. -- Vladimir Lenin 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] opusdsp: add ability to modify deemphasis constant
On Wed, Apr 24, 2024 at 12:58:54PM +0200, Lynne wrote: > Apr 24, 2024, 10:54 by d...@lynne.ee: > > > xHE-AAC relies on the same postfilter mechanism > > that Opus uses to improve clarity (albeit with a steeper > > deemphasis filter). > > > > The code to apply it is identical, it's still just a > > simple IIR low-pass filter. This commit makes it possible > > to use alternative constants. > > > > Version 2 changes: > > Move the deemphasis constant table to opustab.c and > > document its values better. > > > > v3 attached, forgot to port the native opus encoder. make V=2 fate-checkasm-opusdsp TESTcheckasm-opusdsp ./tests/fate-run.sh fate-checkasm-opusdsp "/home/michael/fatesamples/fate/fate-suite/" "" "/home/michael/ffmpeg-git/ffmpeg" 'run tests/checkasm/checkasm --test=opusdsp' 'null' '' '' '1' '' '' '' '' '' '' '' '' '' '' /home/michael/ffmpeg-git/ffmpeg/tests/checkasm/checkasm --test=opusdsp Test checkasm-opusdsp failed. Look at tests/data/fate/checkasm-opusdsp.err for details. checkasm: using random seed 4190264620 FMA3: - opusdsp.postfilter_15 [OK] - opusdsp.postfilter_512 [OK] - opusdsp.postfilter_1022 [OK] deemphasis_fma3 (fatal signal 11: Segmentation fault) - opusdsp.deemphasis [FAILED] checkasm: 1 of 4 tests have failed threads=1 make: *** [tests/Makefile:311: fate-checkasm-opusdsp] Error 1 [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB During times of universal deceit, telling the truth becomes a revolutionary act. -- George Orwell 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] 5 year plan & Inovation
On Thu, Apr 25, 2024 at 12:50:02AM +0200, Tomas Härdin wrote: > ons 2024-04-17 klockan 15:58 +0200 skrev Michael Niedermayer: > > > * ffchat > > (expand into realtime chat / zoom) this would > > bring in more users and developers, and we basically have almost > > all parts for it already but some people where against it > > You mean inventing a new chat protocol? If so then please don't. We If theres an existing protocol that serves the purpose then theres no need to invent a new one I think at a minimum it should have "secure and private by default and always" (there are many solutions already when one is willing to give up security/privacy) thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB I have often repented speaking, but never of holding my tongue. -- Xenocrates 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] 5 year plan & Inovation
On Thu, Apr 25, 2024 at 12:50 AM Tomas Härdin wrote: > A large long term project that would help immensely with security is > moving to a proper parsing framework, rather than the present shotgun > parsing approach. But this might be such a large undertaking that it's > better to start from scratch. > > A more modest proposal is to improve subtitle support. Streaming > support could also be improved, and would be very much with the times. > The fact that we can't pass MPEG-TS through unmolested isn't great. Are point like these two, setting up a gitlab, etc, collected on a wiki somewhere? Would make writing something like the big recent funding application a bunch easier next time. Cheers, Dee ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2] avcodec/jpeg2000dec: support of 2 fields in 1 AVPacket
ons 2024-04-24 klockan 13:20 +0200 skrev Jerome Martinez: > Hi, I'm bumping this patch proposal for avoiding a situation where > FFmpeg skips half the visual content when 2 jpeg2000 codestreams are > present in one frame. I re-reviewed this discussion and think I > answered > all concerns. I'm hesitant with patch v3 because I consider that > touching frame_worker_thread for this feature is not so useful but I > am > ok with either patch v2 or v3. Did you look at doing this further up, say in demux.c? Because adding codec-specific logic for this seems wrong, when J2K is far from the only codec that can be used like this in MXF.. /Tomas ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] 5 year plan & Inovation
ons 2024-04-17 klockan 15:58 +0200 skrev Michael Niedermayer: > * ffchat > (expand into realtime chat / zoom) this would > bring in more users and developers, and we basically have almost > all parts for it already but some people where against it You mean inventing a new chat protocol? If so then please don't. We don't need even more fragmentation in that space - heretical projects like Matrix are bad enough. It's also widely out of scope. > * AI / neural network filters and codecs > The future seems to be AI based. Future Filters and Codecs will > use > neural networks. FFmpeg can be at the forefront, developing these New codecs are better developed as separate projects. The IETF has a group dedicated to codec development. In fact they seem to be working on ML codecs right now: https://datatracker.ietf.org/wg/mlcodec/about/ > * [your idea here] A large long term project that would help immensely with security is moving to a proper parsing framework, rather than the present shotgun parsing approach. But this might be such a large undertaking that it's better to start from scratch. A more modest proposal is to improve subtitle support. Streaming support could also be improved, and would be very much with the times. The fact that we can't pass MPEG-TS through unmolested isn't great. /Tomas ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2] avcodec/nvenc: High bit depth encoding for HEVC
On 19.04.2024 10:38, Diego Felix de Souza via ffmpeg-devel wrote:
From: Diego Felix de Souza
Adding 10-bit encoding support for HEVC if the input is 8-bit. In
case of 8-bit input content, NVENC performs an internal CUDA 8 to
10-bit conversion of the input prior to encoding. Currently, only
AV1 supports encoding 8-bit content as 10-bit.
Signed-off-by: Diego Felix de Souza
---
libavcodec/nvenc.c | 10 +-
libavcodec/nvenc_hevc.c | 3 +++
2 files changed, 8 insertions(+), 5 deletions(-)
diff --git a/libavcodec/nvenc.c b/libavcodec/nvenc.c
index 794174a53f..e48224347d 100644
--- a/libavcodec/nvenc.c
+++ b/libavcodec/nvenc.c
@@ -514,7 +514,7 @@ static int nvenc_check_capabilities(AVCodecContext *avctx)
}
ret = nvenc_check_cap(avctx, NV_ENC_CAPS_SUPPORT_10BIT_ENCODE);
-if (IS_10BIT(ctx->data_pix_fmt) && ret <= 0) {
+if ((IS_10BIT(ctx->data_pix_fmt) || ctx->highbitdepth) && ret <= 0) {
av_log(avctx, AV_LOG_WARNING, "10 bit encode not supported\n");
return AVERROR(ENOSYS);
}
@@ -1420,8 +1420,8 @@ static av_cold int nvenc_setup_hevc_config(AVCodecContext
*avctx)
break;
}
-// force setting profile as main10 if input is 10 bit
-if (IS_10BIT(ctx->data_pix_fmt)) {
+// force setting profile as main10 if input is 10 bit or if it should be
encoded as 10 bit
+if (IS_10BIT(ctx->data_pix_fmt) || ctx->highbitdepth) {
cc->profileGUID = NV_ENC_HEVC_PROFILE_MAIN10_GUID;
avctx->profile = AV_PROFILE_HEVC_MAIN_10;
}
@@ -1435,8 +1435,8 @@ static av_cold int nvenc_setup_hevc_config(AVCodecContext
*avctx)
hevc->chromaFormatIDC = IS_YUV444(ctx->data_pix_fmt) ? 3 : 1;
#ifdef NVENC_HAVE_NEW_BIT_DEPTH_API
-hevc->inputBitDepth = hevc->outputBitDepth =
-IS_10BIT(ctx->data_pix_fmt) ? NV_ENC_BIT_DEPTH_10 : NV_ENC_BIT_DEPTH_8;
+hevc->inputBitDepth = IS_10BIT(ctx->data_pix_fmt) ? NV_ENC_BIT_DEPTH_10 :
NV_ENC_BIT_DEPTH_8;
+hevc->outputBitDepth = (IS_10BIT(ctx->data_pix_fmt) || ctx->highbitdepth)
? NV_ENC_BIT_DEPTH_10 : NV_ENC_BIT_DEPTH_8;
#else
hevc->pixelBitDepthMinus8 = IS_10BIT(ctx->data_pix_fmt) ? 2 : 0;
#endif
diff --git a/libavcodec/nvenc_hevc.c b/libavcodec/nvenc_hevc.c
index b949cb1bd7..d54e5f2512 100644
--- a/libavcodec/nvenc_hevc.c
+++ b/libavcodec/nvenc_hevc.c
@@ -183,6 +183,9 @@ static const AVOption options[] = {
{ "fullres", "Two Pass encoding is enabled where first Pass is full
resolution",
0,
AV_OPT_TYPE_CONST, { .i64 = NV_ENC_TWO_PASS_FULL_RESOLUTION },0,
0, VE, .unit = "multipass" },
#endif
+#ifdef NVENC_HAVE_NEW_BIT_DEPTH_API
+{ "highbitdepth", "Enable 10 bit encode for 8 bit
input",OFFSET(highbitdepth),AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0, 1, VE },
+#endif
#ifdef NVENC_HAVE_LDKFS
{ "ldkfs","Low delay key frame scale; Specifies the Scene Change frame
size increase allowed in case of single frame VBV and CBR",
OFFSET(ldkfs),
AV_OPT_TYPE_INT, { .i64 = 0 }, 0, UCHAR_MAX, VE },
--
2.34.1
applied, 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] Inconsistent usage of AVFieldOrder values
On Mon, 22 Apr 2024, Devin Heitmueller wrote: Hello, I suspect this topic has been visited a number of times over the years, but I figured I should re-raise it. In the compressed domain, field ordering is represented by the AVFieldOrder enumeration. Among the interlaced possibilities, you've got four combinations: AV_FIELD_TT, AV_FIELD_BB, AV_FIELD_TB, AV_FIELD_BT. The last two characters indicate the coding and display order respectively. That is how it is documented, but likely it is not how it actually works. The whole mess is originated from the QuickTime specification which contradicts with an Apple technical note. See this discussion: https://sourceforge.net/p/mediainfo/bugs/841/ Long story short, AV_FIELD_TB means top field first in practice, AV_FIELD_BT means bottom field first in practice. I think most of the code follows this interpretation, and not the actual documentation. AV_FIELD_BB and AV_FIELD_TT tries to signal field order for separate field encodings, but quite possibly sometimes (mis)used for ordinary field order signalling as well... Only a subset of these possible values are able to be represented in ffmpeg's AVFrame facility (specifically AV_FIELD_TT and AV_FIELD_TB). This is because interlaced AVFrames are always represented as interleaved with top field coded first, and the AV_FRAME_FLAG_TOP_FIELD_FIRST flag (previously the top_field_first member) is used to dictate the display order. I'm not proposing we make any change to this behavior at this time. I'm seeing use cases (including within the ffmpeg tree) where I suspect the developer is misunderstanding the meaning of these values, and I want to solicit feedback on whether patches would be accepted to correct such usage, even if it results in breaking applications that expect the incorrect values. For example, the decklink input module (libavdevice/decklink_dec.cpp) sets the values on the v210 packets to either AV_FIELD_TT or AV_FIELD_BB depending on whether the display order is top field first or bottom field first. While the AV_FIELD_TT values is correct, the use of AV_FIELD_BB is incorrect since all frames delivered by the driver are always coded as top-field-first (i.e. interlaced frames with a display order of bottom first should be AV_FIELD_TB). I guess the reason for using TT/BB was that it is not contriversal... But TB is BFF according to docs, but it is interpreted as TFF in reality... I'm seeing numerous cases such as the above, in decoders and encoders, libavformat/libavdevice modules, as well as in third party applications. I guess my question is: if I submit patches which fix such cases where I find them, will they be rejected because they are a change in behavior and might very well break existing applications that expect the incorrect values? I would like the libraries to report the correct values in a consistent manner, but I recognize this may cause some breakage in existing applications. Making changes out of the blue likely won't be acceptable. If a justified plan is presented to untangle this, then maybe *some* breakage is acceptable, but I don't honestly know. Some random ideas: - Consider fixing the documentation (and the textual description of the field orders) instead of changing behaviour. - Try to collect commercial samples and see what they contain for TFF/BFF content, separete fields or interleaved, compressed or uncompressed. - Go over the codebase and see which component is using which interpretation in practice, make a list, see if there is a significant majority... Regards, Marton ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] 5 year plan & Inovation
On Tue, Apr 23, 2024 at 03:12:59PM +0300, Rémi Denis-Courmont wrote: > > > Le 21 avril 2024 23:40:08 GMT+03:00, Michael Niedermayer > a écrit : > >On Sun, Apr 21, 2024 at 05:11:36PM +0800, Rémi Denis-Courmont wrote: > >> > >> > >> Le 17 avril 2024 21:58:32 GMT+08:00, Michael Niedermayer > >> a écrit : > >> >Hi all > >> > > >> >The pace of inovation in FFmpeg has been slowing down. > >> >Most work is concentarted nowadays on code refactoring, and adding > >> >support for new codecs and formats. > >> > >> OSS projects of age similar to FFmpeg are either mature (like FFmpeg), or > >> more or less dead. Besides, FFmpeg is an established brand, which means > >> that it's expected to be good at what it's been doing... and not expected > >> to be good at anything else. > >> > >> Of course there are also specific aspects: back then, every company made > >> up its own codecs. Nowadays, there's at most three tracks (for video): > >> H.26x, Chinese AVSx and AV-x, while AVC or HEVC have become "good enough" > >> for most applications. > >> > >> If (generic) you want to work on radical innovation, I think you will be > >> better served by creating a new project. Both the FFmpeg project structure > >> and brand would probably do you a disservice otherwise. > > > >I will disagree on this a bit > > > >If we for a moment look at the commerical world (but its not fundamentally > >different in OSS) > > > >Projects/Companies are created to fill some need, initially they > >often need to concentarte on a narrow market because they dont have the > >resources to do "everything" and if they try they go bankrupt. > >Once they are established and have the resources they grow or they die > > > >Microsoft started with a OS in 1985, added an office suite in 1990 > >internet explorer in 1995, xbox in 2001, Microsoft Azure in 2008 > >and you can fill in more. > >Today Microsoft is one of the largest companies in teh world. > > Microsoft expanded into new fields with Xbox and Azure, yes. But Windows is > still an OS, and Office is still a (un)productivity suite. > > Accordingly, maybe you can innovate with a new project within the same legal > entity as FFmpeg (be it SPI, FFlabs or whatever). > > But FFmpeg as a software project is not a suitable venue for radical new > innovation. Microsofts OS does not limit what can be installed to whats in MS main repository, FFmpeg does Microsoft windows from a user POV includes internet explorer IIRC. Its not a seperate product from just the legal entity. It was not in the first OS from microsoft microsofts first OS MS-DOS 1.0 ? looks slightly different than the current latest OS. There was radical innovation, if one likes MS or hate them. > > >You can do the same with apple, google, or others. > > Sure but you can't do the same with iPhone or Google Search. of course you can, googles search inovated. Theres a image search a audio search news, travel, shoping. These did not exist in the initial google search. And while i dont know, i suspect google search is very good at finding google products. Google didnt became that big by simply "not being evil" But lets not assume, lets try, if i search for maps i get Google Maps as first entry. or finance, 2nd entry is https://www.google.com/finance/ And the iphone uses apples operating system and their app store, with many apple apps. Check the first iphone and compare it to the latest there is huge inovation with what you can do with all the software that comes preinstalled and also what you can install later. Thats in stark contrast to "FFmpeg as a software project is not a suitable venue for radical new innovation" when did you last use siri with your iphone ? siri was added in iphone 4s IIUC. Thats a big change. I can ultimately only repeat my oppinion. FFmpeg will innovate or FFmpeg will stagnate and eventually be replaced by some other project that doesnt have an opposition to innovation. IMHO we need to find out what direction (of innovation or lack thereof) people want. This RFC thread is kind of the first step. 2nd step would be a vote. thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The day soldiers stop bringing you their problems is the day you have stopped leading them. They have either lost confidence that you can help or concluded you do not care. Either case is a failure of leadership. - Colin Powell 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] fate: allow https for git URLs
On 24.04.2024 22:53, Alexander Strasser via ffmpeg-devel wrote:
On 2024-04-24 22:26 +0200, Timo Rothenpieler wrote:
On 24.04.2024 22:12, Alexander Strasser via ffmpeg-devel wrote:
On 2024-04-24 22:01 +0200, Timo Rothenpieler wrote:
---
tests/fate.sh | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/tests/fate.sh b/tests/fate.sh
index c5ee18de80..4081e865ae 100755
--- a/tests/fate.sh
+++ b/tests/fate.sh
@@ -30,14 +30,14 @@ lock(){
checkout(){
case "$repo" in
file:*|/*) src="${repo#file:}" ;;
-git:*) git clone --quiet --branch "$branch" "$repo" "$src" ;;
+git:*|https:*) git clone --quiet --branch "$branch" "$repo" "$src" ;;
esac
}
update()(
cd ${src} || return
case "$repo" in
-git:*) git fetch --quiet --force && git reset --quiet --hard
"origin/$branch" ;;
+git:*|https:*) git fetch --quiet --force && git reset --quiet --hard
"origin/$branch" ;;
esac
)
If you manually clone the repo, you can use whatever you like anyway, since
Sorry my initial wording was probably ambiguous.
I meant in the repo variable in a fate_config.sh
it never actually uses the URL for anything after the initial clone.
The URL isn't used per se, but it's used to decide whether to
git fetch or not inside the call to update, isn't it?
Yeah, that's pretty much the only thing it's used for.
I also considered to turn the check around, and always assume it's a
valid git URL unless the file: thingy is recognized.
That way ssh URLs and cloning from local paths would become possible.
But that runs a higher risk of breaking someones setup.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 4/5] doc/examples/qsv_transcode: Simplify str_to_dict() loop
On Wed, Apr 24, 2024 at 05:18:55AM +, Xiang, Haihao wrote: > On Wo, 2024-04-24 at 03:45 +0200, Michael Niedermayer wrote: > > Fixes: CID1517022 Logically dead code > > > > Sponsored-by: Sovereign Tech Fund > > Signed-off-by: Michael Niedermayer > > --- > > doc/examples/qsv_transcode.c | 3 +-- > > 1 file changed, 1 insertion(+), 2 deletions(-) > > > > diff --git a/doc/examples/qsv_transcode.c b/doc/examples/qsv_transcode.c > > index a4440a3403f..8e843ddd84c 100644 > > --- a/doc/examples/qsv_transcode.c > > +++ b/doc/examples/qsv_transcode.c > > @@ -76,8 +76,7 @@ static int str_to_dict(char* optstr, AVDictionary **opt) > > if (value == NULL) > > return AVERROR(EINVAL); > > av_dict_set(opt, key, value, 0); > > - } while(key != NULL); > > - return 0; > > + } while(1); > > } > > > > static int dynamic_set_parameter(AVCodecContext *avctx) > > LGTM, thanks for catching & fixing this. will apply thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Freedom in capitalist society always remains about the same as it was in ancient Greek republics: Freedom for slave owners. -- Vladimir Lenin 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/5] doc/examples/vaapi_transcode: Simplify loop
On Wed, Apr 24, 2024 at 02:39:45PM +0800, myp...@gmail.com wrote: > On Wed, Apr 24, 2024 at 9:45 AM Michael Niedermayer > wrote: > > > > Fixes: CID1428858(1/2) Logically dead code > > > > Sponsored-by: Sovereign Tech Fund > > Signed-off-by: Michael Niedermayer > > --- > > doc/examples/vaapi_transcode.c | 4 +--- > > 1 file changed, 1 insertion(+), 3 deletions(-) > > > > diff --git a/doc/examples/vaapi_transcode.c b/doc/examples/vaapi_transcode.c > > index 8367cb30404..e1b7a438836 100644 > > --- a/doc/examples/vaapi_transcode.c > > +++ b/doc/examples/vaapi_transcode.c > > @@ -215,10 +215,8 @@ static int dec_enc(AVPacket *pkt, const AVCodec > > *enc_codec) > > > > fail: > > av_frame_free(); > > -if (ret < 0) > > -return ret; > > } > > -return 0; > > +return ret; > > } > > > it's ok, thx will apply thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB I have often repented speaking, but never of holding my tongue. -- Xenocrates 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 2/5] doc/examples/qsv_transcode: Simplify loop
On Wed, Apr 24, 2024 at 05:25:11AM +, Xiang, Haihao wrote: > On Wo, 2024-04-24 at 03:45 +0200, Michael Niedermayer wrote: > > Fixes: CID1428858(2/2) Logically dead code > > > > Sponsored-by: Sovereign Tech Fund > > Signed-off-by: Michael Niedermayer > > --- > > doc/examples/qsv_transcode.c | 4 +--- > > 1 file changed, 1 insertion(+), 3 deletions(-) > > > > diff --git a/doc/examples/qsv_transcode.c b/doc/examples/qsv_transcode.c > > index 8e7d2899f12..a4440a3403f 100644 > > --- a/doc/examples/qsv_transcode.c > > +++ b/doc/examples/qsv_transcode.c > > @@ -335,10 +335,8 @@ static int dec_enc(AVPacket *pkt, const AVCodec > > *enc_codec, char *optstr) > > > > fail: > > av_frame_free(); > > - if (ret < 0) > > - return ret; > > } > > - return 0; > > + return ret; > > } > > > > int main(int argc, char **argv) > > LGTM will apply thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Take away the freedom of one citizen and you will be jailed, take away the freedom of all citizens and you will be congratulated by your peers in Parliament. 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] fate: allow https for git URLs
On 2024-04-24 22:26 +0200, Timo Rothenpieler wrote:
> On 24.04.2024 22:12, Alexander Strasser via ffmpeg-devel wrote:
> > On 2024-04-24 22:01 +0200, Timo Rothenpieler wrote:
> > > ---
> > > tests/fate.sh | 4 ++--
> > > 1 file changed, 2 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/tests/fate.sh b/tests/fate.sh
> > > index c5ee18de80..4081e865ae 100755
> > > --- a/tests/fate.sh
> > > +++ b/tests/fate.sh
> > > @@ -30,14 +30,14 @@ lock(){
> > > checkout(){
> > > case "$repo" in
> > > file:*|/*) src="${repo#file:}" ;;
> > > -git:*) git clone --quiet --branch "$branch" "$repo" "$src" ;;
> > > +git:*|https:*) git clone --quiet --branch "$branch" "$repo"
> > > "$src" ;;
> > > esac
> > > }
> > >
> > > update()(
> > > cd ${src} || return
> > > case "$repo" in
> > > -git:*) git fetch --quiet --force && git reset --quiet --hard
> > > "origin/$branch" ;;
> > > +git:*|https:*) git fetch --quiet --force && git reset --quiet
> > > --hard "origin/$branch" ;;
> > > esac
> > > )
> >
>
> If you manually clone the repo, you can use whatever you like anyway, since
Sorry my initial wording was probably ambiguous.
I meant in the repo variable in a fate_config.sh
> it never actually uses the URL for anything after the initial clone.
The URL isn't used per se, but it's used to decide whether to
git fetch or not inside the call to update, isn't it?
Alexander
___
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: allow https for git URLs
On 24.04.2024 22:12, Alexander Strasser via ffmpeg-devel wrote:
On 2024-04-24 22:01 +0200, Timo Rothenpieler wrote:
---
tests/fate.sh | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/tests/fate.sh b/tests/fate.sh
index c5ee18de80..4081e865ae 100755
--- a/tests/fate.sh
+++ b/tests/fate.sh
@@ -30,14 +30,14 @@ lock(){
checkout(){
case "$repo" in
file:*|/*) src="${repo#file:}" ;;
-git:*) git clone --quiet --branch "$branch" "$repo" "$src" ;;
+git:*|https:*) git clone --quiet --branch "$branch" "$repo" "$src" ;;
esac
}
update()(
cd ${src} || return
case "$repo" in
-git:*) git fetch --quiet --force && git reset --quiet --hard
"origin/$branch" ;;
+git:*|https:*) git fetch --quiet --force && git reset --quiet --hard
"origin/$branch" ;;
esac
)
If you manually clone the repo, you can use whatever you like anyway,
since it never actually uses the URL for anything after the initial clone.
___
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: allow https for git URLs
On 2024-04-24 22:01 +0200, Timo Rothenpieler wrote:
> ---
> tests/fate.sh | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/tests/fate.sh b/tests/fate.sh
> index c5ee18de80..4081e865ae 100755
> --- a/tests/fate.sh
> +++ b/tests/fate.sh
> @@ -30,14 +30,14 @@ lock(){
> checkout(){
> case "$repo" in
> file:*|/*) src="${repo#file:}" ;;
> -git:*) git clone --quiet --branch "$branch" "$repo" "$src" ;;
> +git:*|https:*) git clone --quiet --branch "$branch" "$repo" "$src" ;;
> esac
> }
>
> update()(
> cd ${src} || return
> case "$repo" in
> -git:*) git fetch --quiet --force && git reset --quiet --hard
> "origin/$branch" ;;
> +git:*|https:*) git fetch --quiet --force && git reset --quiet --hard
> "origin/$branch" ;;
> esac
> )
Should be OK if tested to work with both git and https URLs in repo.
Alexander
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] fate: allow https for git URLs
---
tests/fate.sh | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/tests/fate.sh b/tests/fate.sh
index c5ee18de80..4081e865ae 100755
--- a/tests/fate.sh
+++ b/tests/fate.sh
@@ -30,14 +30,14 @@ lock(){
checkout(){
case "$repo" in
file:*|/*) src="${repo#file:}" ;;
-git:*) git clone --quiet --branch "$branch" "$repo" "$src" ;;
+git:*|https:*) git clone --quiet --branch "$branch" "$repo" "$src" ;;
esac
}
update()(
cd ${src} || return
case "$repo" in
-git:*) git fetch --quiet --force && git reset --quiet --hard
"origin/$branch" ;;
+git:*|https:*) git fetch --quiet --force && git reset --quiet --hard
"origin/$branch" ;;
esac
)
--
2.43.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 0/9] HTTP rate limiting and retry improvements
On 4/24/2024 12:13 PM, Martin Storsjö wrote: > I had a look over this patchset, and I had a handful of minor comments, > but overall, the patchset seems fine to me. Thanks! Applied all your comments. Will wait a day and then push if no others appear. - Derek ___ 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 6/9] avformat/http: Add options to set the max number of connection retries
On 4/24/2024 12:08 PM, Martin Storsjö wrote: > Minor inconsistency; the corresponding variable in the other function was > called conn_attempts, as a plural. Renamed to the plural version. - Derek ___ 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 2/9] avformat/http: Use AVERROR_HTTP_TOO_MANY_REQUESTS
On 4/24/2024 11:58 AM, Martin Storsjö wrote: > This function seems to handle both the literal status codes, like 429, and > also AVERROR style error codes, as when called from handle_http_errors, so > perhaps it would be good for consistency to add the AVERROR here too. Good catch. Added. - Derek ___ 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 2/9] avformat/http: Use AVERROR_HTTP_TOO_MANY_REQUESTS
On 4/24/2024 11:53 AM, Martin Storsjö wrote: > Typo in the commit message Fixed locally. - Derek ___ 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 4/9] avformat/http: Add support for Retry-After header
On 4/24/2024 12:06 PM, Martin Storsjö wrote:
> Is this feature standardized in a RFC, or is it some other spec somewhere?
> I think it would be nice with a link to a spec in the commit message here.
It is in the RFC for 429 I noted in the commit I added that: RFC6585. It is also
probably in the 503 and 301 RFCs.
See also: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Retry-After
I will add those.
>> +if (s->respect_retry_after && s->retry_after > 0) {
>> +reconnect_delay = s->retry_after;
>
> It'd be nice with a comment to clarify the units of both values here,
> which apparently both happen to be integer seconds?
Yes, seconds.
I have added:
/* Both the Retry-After header and the option are in seconds. */
>> +} else if (!av_strcasecmp(tag, "Retry-After")) {
>> +s->retry_after = strtoul(p, NULL, 10);
>
> Can you add a comment here, to clarify what unit the value is expressed
> in?
Added:
/* Specifies how long to wait before retrying in second. */
- Derek
___
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] checkasm/h264dsp: support checking more idct depths
Signed-off-by: J. Dekker
---
tests/checkasm/h264dsp.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/tests/checkasm/h264dsp.c b/tests/checkasm/h264dsp.c
index 0f484e3f43..5cb646ae49 100644
--- a/tests/checkasm/h264dsp.c
+++ b/tests/checkasm/h264dsp.c
@@ -173,6 +173,7 @@ static void dct8x8(int16_t *coef, int bit_depth)
static void check_idct(void)
{
+static const int depths[5] = { 8, 9, 10, 12, 14 };
LOCAL_ALIGNED_16(uint8_t, src, [8 * 8 * 2]);
LOCAL_ALIGNED_16(uint8_t, dst, [8 * 8 * 2]);
LOCAL_ALIGNED_16(uint8_t, dst0, [8 * 8 * 2]);
@@ -181,10 +182,11 @@ static void check_idct(void)
LOCAL_ALIGNED_16(int16_t, subcoef0, [8 * 8 * 2]);
LOCAL_ALIGNED_16(int16_t, subcoef1, [8 * 8 * 2]);
H264DSPContext h;
-int bit_depth, sz, align, dc;
+int bit_depth, sz, align, dc, i;
declare_func_emms(AV_CPU_FLAG_MMX, void, uint8_t *dst, int16_t *block, int
stride);
-for (bit_depth = 8; bit_depth <= 10; bit_depth++) {
+for (i = 0; i < 5; i++) {
+bit_depth = depths[i];
ff_h264dsp_init(, bit_depth, 1);
for (sz = 4; sz <= 8; sz += 4) {
randomize_buffers();
--
2.44.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 1/2] avfilter/riscv: build afir only if required
Signed-off-by: J. Dekker --- libavfilter/riscv/Makefile | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/libavfilter/riscv/Makefile b/libavfilter/riscv/Makefile index 0b968a9c0d..277dde2aed 100644 --- a/libavfilter/riscv/Makefile +++ b/libavfilter/riscv/Makefile @@ -1,2 +1,2 @@ -OBJS += riscv/af_afir_init.o -RVV-OBJS += riscv/af_afir_rvv.o +OBJS-$(CONFIG_AFIR_FILTER) += riscv/af_afir_init.o +RVV-OBJS-$(CONFIG_AFIR_FILTER) += riscv/af_afir_rvv.o -- 2.44.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 v3 1/4] lavu: Remove libva 1.x support
On Ma, 2024-04-22 at 22:41 +0100, Mark Thompson wrote:
> libva 2.0 was released in 2017 and the 2.x versions are included in all
> supported distributions nowadays.
> ---
> Rebased.
>
> I think we can also drop the other quirks? They are for the proprietary media
> SDK driver (which I think is dead?) and the VDPAU wrapper (which I don't think
> was ever updated for libva 2?).
Agree, please drop these quirks in a new patch.
BTW I think we should require VA-API 1.x firstly, otherwise if someone has VA-
API 0.x, he/she will get errors when building this commit.
Thanks
Haihao
>
>
> libavutil/hwcontext_vaapi.c | 22 --
> 1 file changed, 22 deletions(-)
>
> diff --git a/libavutil/hwcontext_vaapi.c b/libavutil/hwcontext_vaapi.c
> index 56d03aa4cd..84bcb78087 100644
> --- a/libavutil/hwcontext_vaapi.c
> +++ b/libavutil/hwcontext_vaapi.c
> @@ -372,14 +372,6 @@ static const struct {
> const char *match_string;
> unsigned int quirks;
> } vaapi_driver_quirks_table[] = {
> -#if !VA_CHECK_VERSION(1, 0, 0)
> - // The i965 driver did not conform before version 2.0.
> - {
> - "Intel i965 (Quick Sync)",
> - "i965",
> - AV_VAAPI_DRIVER_QUIRK_RENDER_PARAM_BUFFERS,
> - },
> -#endif
> {
> "Intel iHD",
> "ubit",
> @@ -1413,7 +1405,6 @@ fail:
> }
> #endif
>
> -#if VA_CHECK_VERSION(0, 36, 0)
> typedef struct VAAPIDRMImageBufferMapping {
> VAImage image;
> VABufferInfo buffer_info;
> @@ -1573,7 +1564,6 @@ fail:
> av_freep();
> return err;
> }
> -#endif
>
> static int vaapi_map_to_drm(AVHWFramesContext *hwfc, AVFrame *dst,
> const AVFrame *src, int flags)
> @@ -1584,10 +1574,7 @@ static int vaapi_map_to_drm(AVHWFramesContext *hwfc,
> AVFrame *dst,
> if (err != AVERROR(ENOSYS))
> return err;
> #endif
> -#if VA_CHECK_VERSION(0, 36, 0)
> return vaapi_map_to_drm_abh(hwfc, dst, src, flags);
> -#endif
> - return AVERROR(ENOSYS);
> }
>
> #endif /* CONFIG_LIBDRM */
> @@ -1637,7 +1624,6 @@ static void vaapi_device_free(AVHWDeviceContext *ctx)
> av_freep();
> }
>
> -#if CONFIG_VAAPI_1
> static void vaapi_device_log_error(void *context, const char *message)
> {
> AVHWDeviceContext *ctx = context;
> @@ -1651,7 +1637,6 @@ static void vaapi_device_log_info(void *context, const
> char *message)
>
> av_log(ctx, AV_LOG_VERBOSE, "libva: %s", message);
> }
> -#endif
>
> static int vaapi_device_connect(AVHWDeviceContext *ctx,
> VADisplay display)
> @@ -1660,10 +1645,8 @@ static int vaapi_device_connect(AVHWDeviceContext *ctx,
> int major, minor;
> VAStatus vas;
>
> -#if CONFIG_VAAPI_1
> vaSetErrorCallback(display, _device_log_error, ctx);
> vaSetInfoCallback (display, _device_log_info, ctx);
> -#endif
>
> hwctx->display = display;
>
> @@ -1907,7 +1890,6 @@ static int vaapi_device_create(AVHWDeviceContext *ctx,
> const char *device,
>
> ent = av_dict_get(opts, "driver", NULL, 0);
> if (ent) {
> -#if VA_CHECK_VERSION(0, 38, 0)
> VAStatus vas;
> vas = vaSetDriverName(display, ent->value);
> if (vas != VA_STATUS_SUCCESS) {
> @@ -1916,10 +1898,6 @@ static int vaapi_device_create(AVHWDeviceContext *ctx,
> const char *device,
> vaTerminate(display);
> return AVERROR_EXTERNAL;
> }
> -#else
> - av_log(ctx, AV_LOG_WARNING, "Driver name setting is not "
> - "supported with this VAAPI version.\n");
> -#endif
> }
>
> return vaapi_device_connect(ctx, display);
___
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] lavc/h265_profile_level: Expand profile compatibility checking
On Ma, 2024-04-22 at 22:22 +0100, Mark Thompson wrote:
> Replace existing get_profile() with find_profile(), which finds the
> lowest compatible profile rather than requiring an exact match.
> ---
> libavcodec/h265_profile_level.c | 73 +
> libavcodec/h265_profile_level.h | 70 ++-
> libavcodec/vaapi_hevc.c | 2 +-
> libavcodec/vdpau_hevc.c | 2 +-
> 4 files changed, 117 insertions(+), 30 deletions(-)
>
> diff --git a/libavcodec/h265_profile_level.c b/libavcodec/h265_profile_level.c
> index 7ff9681f65..4bc72414cb 100644
> --- a/libavcodec/h265_profile_level.c
> +++ b/libavcodec/h265_profile_level.c
> @@ -119,41 +119,60 @@ static const H265ProfileDescriptor h265_profiles[] = {
> 5, 1, 0, 0, 0, 0, 0, 0, 0, 1, 0, 2, 4000, 4400, 6.000, 0.5, 6 },
> };
>
> +_Static_assert(H265_PROFILE_COUNT == FF_ARRAY_ELEMS(h265_profiles),
> + "Incorrect H.265 profiles table.");
>
> -const H265ProfileDescriptor *ff_h265_get_profile(const
> H265RawProfileTierLevel *ptl)
> +
> +const int ff_h265_profile_compatible(const H265RawProfileTierLevel *ptl,
> + int profile)
> {
> - int i;
> + const H265ProfileDescriptor *desc;
> +
> + av_assert0(profile >= 0 && profile < H265_PROFILE_COUNT);
>
> if (ptl->general_profile_space)
> - return NULL;
> + return 0;
>
> - for (i = 0; i < FF_ARRAY_ELEMS(h265_profiles); i++) {
> - const H265ProfileDescriptor *profile = _profiles[i];
> + desc = _profiles[profile];
>
> - if (ptl->general_profile_idc &&
> - ptl->general_profile_idc != profile->profile_idc)
> - continue;
> - if (!ptl->general_profile_compatibility_flag[profile->profile_idc])
> - continue;
> + if (ptl->general_profile_idc &&
> + ptl->general_profile_idc != desc->profile_idc)
> + return 0;
> + if (!ptl->general_profile_compatibility_flag[desc->profile_idc])
> + return 0;
>
> -#define check_flag(name) \
> - if (profile->name < 2) { \
> - if (profile->name != ptl->general_ ## name ## _constraint_flag) \
> - continue; \
> - }
> - check_flag(max_14bit);
> - check_flag(max_12bit);
> - check_flag(max_10bit);
> - check_flag(max_8bit);
> - check_flag(max_422chroma);
> - check_flag(max_420chroma);
> - check_flag(max_monochrome);
> - check_flag(intra);
> - check_flag(one_picture_only);
> - check_flag(lower_bit_rate);
> +#define check_flag(flag) \
> + if (desc->flag < 2 && \
> + desc->flag > ptl->general_ ## flag ## _constraint_flag) \
> + return 0;
> + check_flag(max_14bit);
> + check_flag(max_12bit);
> + check_flag(max_10bit);
> + check_flag(max_8bit);
> + check_flag(max_422chroma);
> + check_flag(max_420chroma);
> + check_flag(max_monochrome);
> + check_flag(intra);
> + check_flag(one_picture_only);
> + check_flag(lower_bit_rate);
> #undef check_flag
>
> - return profile;
> + return 1;
> +}
> +
> +
> +const H265ProfileDescriptor *ff_h265_get_profile(int profile)
> +{
> + av_assert0(profile >= 0 && profile < H265_PROFILE_COUNT);
> +
> + return _profiles[profile];
> +}
> +
> +const H265ProfileDescriptor *ff_h265_find_profile(const
> H265RawProfileTierLevel *ptl)
> +{
> + for (int p = 0; p < H265_PROFILE_COUNT; p++) {
> + if (ff_h265_profile_compatible(ptl, p))
> + return _profiles[p];
> }
>
> return NULL;
> @@ -171,7 +190,7 @@ const H265LevelDescriptor *ff_h265_guess_level(const
> H265RawProfileTierLevel *pt
> int i;
>
> if (ptl)
> - profile = ff_h265_get_profile(ptl);
> + profile = ff_h265_find_profile(ptl);
> else
> profile = NULL;
> if (!profile) {
> diff --git a/libavcodec/h265_profile_level.h b/libavcodec/h265_profile_level.h
> index cd30ac5c50..f403f63211 100644
> --- a/libavcodec/h265_profile_level.h
> +++ b/libavcodec/h265_profile_level.h
> @@ -24,6 +24,49 @@
> #include "cbs_h265.h"
>
>
> +// Enumeration of all H.265 profiles.
> +// The list is ordered to match table A.10; numeric values are an index
> +// into the latest version of this table and have no codec meaning.
> +enum {
> + H265_PROFILE_MONOCHROME,
> + H265_PROFILE_MONOCHROME_10,
> + H265_PROFILE_MONOCHROME_12,
> + H265_PROFILE_MONOCHROME_16,
> + H265_PROFILE_MAIN,
> + H265_PROFILE_SCREEN_EXTENDED_MAIN,
> + H265_PROFILE_MAIN_10,
> + H265_PROFILE_SCREEN_EXTENDED_MAIN_10,
> + H265_PROFILE_MAIN_12,
> + H265_PROFILE_MAIN_STILL_PICTURE,
> + H265_PROFILE_MAIN_10_STILL_PICTURE,
> + H265_PROFILE_MAIN_422_10,
> + H265_PROFILE_MAIN_422_12,
> + H265_PROFILE_MAIN_444,
> + H265_PROFILE_HIGH_THROUGHPUT_444,
> + H265_PROFILE_SCREEN_EXTENDED_MAIN_444,
> + H265_PROFILE_SCREEN_EXTENDED_HIGH_THROUGHPUT_444,
> + H265_PROFILE_MAIN_444_10,
> +
Re: [FFmpeg-devel] [PATCH 2/2] lavc/vaapi_hevc: Don't require exact profiles
On Ma, 2024-04-22 at 22:23 +0100, Mark Thompson wrote:
> Rather than turning the constraint flags into a single profile and then
> searching for that profile (and failing if it doesn't match any profile
> exactly), instead search all supported profiles and use the first one
> which supports the given set of constraint flags.
> ---
> This fixes decode of rext 8-bit 4:2:0; it will correctly pick Main 12 or Main
> 4:2:2 10 or Main 4:4:4 (first one available) to use as the decoding profile
> after this patch.
sw decoding and vaapi decoding might have different bits (There is the same
issue if applying Fei's patchset).
For example:
$ ffmpeg -hwaccel vaapi -f lavfi -i testsrc -vf 'format=nv12,hwupload' -c:v
hevc_vaapi -profile:v rext -vframes 30 -y out.mp4
8bit ouput if using sw decoding:
$ ffmpeg -i out.mp4 -f null -
[...]
Stream #0:0(und): Video: wrapped_avframe, yuv420p(tv, progressive), 320x240 [SAR
1:1 DAR 4:3], q=2-31, 200 kb/s, 25 fps, 25 tbn (default)
12bit output if using vaapi decoding:
$ ffmpeg -hwaccel vaapi -i out.mp4 -f null -
[...]
Stream #0:0(und): Video: wrapped_avframe, p012le(tv, progressive), 320x240 [SAR
1:1 DAR 4:3], q=2-31, 200 kb/s, 25 fps, 25 tbn (default)
Thanks
Haihao
>
> libavcodec/vaapi_decode.c | 45 ---
> libavcodec/vaapi_hevc.c | 95 +--
> libavcodec/vaapi_hevc.h | 4 +-
> 3 files changed, 83 insertions(+), 61 deletions(-)
>
> diff --git a/libavcodec/vaapi_decode.c b/libavcodec/vaapi_decode.c
> index 21b273cd0f..f1327464f5 100644
> --- a/libavcodec/vaapi_decode.c
> +++ b/libavcodec/vaapi_decode.c
> @@ -387,7 +387,9 @@ static const struct {
> enum AVCodecID codec_id;
> int codec_profile;
> VAProfile va_profile;
> - VAProfile (*profile_parser)(AVCodecContext *avctx);
> + VAProfile (*match_profile)(AVCodecContext *avctx,
> + const VAProfile *profile_list,
> + int profile_count);
> } vaapi_profile_map[] = {
> #define MAP(c, p, v, ...) { AV_CODEC_ID_ ## c, AV_PROFILE_ ## p, VAProfile ##
> v, __VA_ARGS__ }
> MAP(MPEG2VIDEO, MPEG2_SIMPLE, MPEG2Simple ),
> @@ -414,9 +416,9 @@ static const struct {
> #endif
> #if VA_CHECK_VERSION(1, 2, 0) && CONFIG_HEVC_VAAPI_HWACCEL
> MAP(HEVC, HEVC_REXT, None,
> - ff_vaapi_parse_hevc_rext_scc_profile ),
> + ff_vaapi_hevc_match_rext_scc_profile ),
> MAP(HEVC, HEVC_SCC, None,
> - ff_vaapi_parse_hevc_rext_scc_profile ),
> + ff_vaapi_hevc_match_rext_scc_profile ),
> #endif
> MAP(MJPEG, MJPEG_HUFFMAN_BASELINE_DCT,
> JPEGBaseline),
> @@ -499,22 +501,33 @@ static int vaapi_decode_make_config(AVCodecContext
> *avctx,
> vaapi_profile_map[i].codec_profile == AV_PROFILE_UNKNOWN)
> profile_match = 1;
>
> - va_profile = vaapi_profile_map[i].profile_parser ?
> - vaapi_profile_map[i].profile_parser(avctx) :
> - vaapi_profile_map[i].va_profile;
> codec_profile = vaapi_profile_map[i].codec_profile;
> -
> - for (j = 0; j < profile_count; j++) {
> - if (va_profile == profile_list[j]) {
> - exact_match = profile_match;
> + if (vaapi_profile_map[i].match_profile) {
> + va_profile =
> + vaapi_profile_map[i].match_profile(avctx, profile_list,
> + profile_count);
> + if (va_profile != VAProfileNone) {
> + matched_va_profile = va_profile;
> + matched_ff_profile = codec_profile;
> + exact_match = 1;
> break;
> }
> - }
> - if (j < profile_count) {
> - matched_va_profile = va_profile;
> - matched_ff_profile = codec_profile;
> - if (exact_match)
> - break;
> + } else {
> + va_profile = vaapi_profile_map[i].va_profile;
> +
> + for (j = 0; j < profile_count; j++) {
> + if (va_profile == profile_list[j]) {
> + exact_match = profile_match;
> + break;
> + }
> + }
> +
> + if (j < profile_count) {
> + matched_va_profile = va_profile;
> + matched_ff_profile = codec_profile;
> + if (exact_match)
> + break;
> + }
> }
> }
> av_freep(_list);
> diff --git a/libavcodec/vaapi_hevc.c b/libavcodec/vaapi_hevc.c
> index 77f55ff8b1..28f7c9280e 100644
> --- a/libavcodec/vaapi_hevc.c
> +++ b/libavcodec/vaapi_hevc.c
> @@ -590,63 +590,70 @@ static int ptl_convert(const PTLCommon *general_ptl,
> H265RawProfileTierLevel *h2
> }
>
> /*
> - * Find exact va_profile for HEVC Range Extension and Screen Content Coding
> Extension
> + * Find compatible
Re: [FFmpeg-devel] [PATCH 0/5] replace scale2ref by scale=rw:rh
On Wed, 24 Apr 2024 16:48:54 +0530 Gyan Doshi wrote: > > > On 2024-04-24 04:21 pm, Niklas Haas wrote: > > As discussed in my previous series for fixing scale2ref[1], this filter > > is fundamentally broken, and the only real fix would be to switch to > > activate(), or ideally FFFrameSync. > > > > [1] https://ffmpeg.org//pipermail/ffmpeg-devel/2024-March/323382.html > > > > The main thing making this difficult is the fact that scale2ref also > > wants to output ref frames to its secondary output, which FFFrameSync > > does not support, and which is ultimately at least part of the root > > cause of trac #10795. > > > > Since this is in principle completely unnecessary (users can just > > 'split' the ref input and have it be consumed by vf_scale), and to make > > the design of this filter a bit more robust and maintainable, switch to > > an approach where vf_scale itself gains the ability to reference > > a secondary input stream, using the "ref_*" series of variables. > > > > This makes the current [i][ri]scale2ref[o][ro] equivalent to the only > > slightly more verbose [ri]split[t][ro]; [i][t]scale=rw:rh[o]. (And > > conversely, it is no longer necessary to use nullsink to consume an > > unused [ro]) > > In principle, a good idea, but how does this impact memory use and speed > in the not-so-uncommon scenario where multiple overlay targets are > scaled 2 ref and then overlaid > e.g. > > in current flow: > > [a][base]scale2ref[a][ref]; > [b][ref]scale2ref[b][ref[; > [c][ref]scale2ref[c][ref[; > [d][ref]scale2ref[d][ref[; > [ref][a]overlay[ref]; > [ref][b]overlay[ref]; > [ref][c]overlay[ref]; > [ref][d]overlay[ref]; > > in new flow: > > [base]split=5[base][refa][refb][refc][refd]; > [a][refa]scale[a]; > [b][refb]scale[b]; > [c][refc]scale[c]; > [d][refd]scale[d]; > [base][a]overlay[outa]; > [outa][b]overlay[outb]; > [outb][c]overlay[outc]; > [outc][d]overlay[out]; > > > Regards, > Gyan I have not tested it exactly, but based on my understanding of libavfilter it shouldn't affect memory usage at all. `split` does not duplicate frame data, it merely creates more references. And since all of the `overlay` filters are upstream of [out], they all consume both of their inputs before any forward progress can be made. So there is no filter in this graph that can buffer more than 1 frame. Actually, I would suspect memory usage to be slightly *lower* on average, because ff_filter_activate_default() first consumes all possible frames from input 1, then all possible frames from input 2, etc.; whereas FFFrameSync consumes from both inputs simultaneously. > > ___ > 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 0/5] replace scale2ref by scale=rw:rh
On 24/04/2024 13:18, Gyan Doshi wrote: On 2024-04-24 04:21 pm, Niklas Haas wrote: As discussed in my previous series for fixing scale2ref[1], this filter is fundamentally broken, and the only real fix would be to switch to activate(), or ideally FFFrameSync. [1] https://ffmpeg.org//pipermail/ffmpeg-devel/2024-March/323382.html The main thing making this difficult is the fact that scale2ref also wants to output ref frames to its secondary output, which FFFrameSync does not support, and which is ultimately at least part of the root cause of trac #10795. Since this is in principle completely unnecessary (users can just 'split' the ref input and have it be consumed by vf_scale), and to make the design of this filter a bit more robust and maintainable, switch to an approach where vf_scale itself gains the ability to reference a secondary input stream, using the "ref_*" series of variables. This makes the current [i][ri]scale2ref[o][ro] equivalent to the only slightly more verbose [ri]split[t][ro]; [i][t]scale=rw:rh[o]. (And conversely, it is no longer necessary to use nullsink to consume an unused [ro]) In principle, a good idea, but how does this impact memory use and speed in the not-so-uncommon scenario where multiple overlay targets are scaled 2 ref and then overlaid e.g. in current flow: [a][base]scale2ref[a][ref]; [b][ref]scale2ref[b][ref[; [c][ref]scale2ref[c][ref[; [d][ref]scale2ref[d][ref[; [ref][a]overlay[ref]; [ref][b]overlay[ref]; [ref][c]overlay[ref]; [ref][d]overlay[ref]; in new flow: [base]split=5[base][refa][refb][refc][refd]; [a][refa]scale[a]; [b][refb]scale[b]; [c][refc]scale[c]; [d][refd]scale[d]; [base][a]overlay[outa]; [outa][b]overlay[outb]; [outb][c]overlay[outc]; [outc][d]overlay[out]; Given that scale never modifies the reference, it just ups the refcount of those frames in the split filter, and will thus not change the memory-use whatsoever. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2] avcodec/jpeg2000dec: support of 2 fields in 1 AVPacket
Hi, I'm bumping this patch proposal for avoiding a situation where FFmpeg skips half the visual content when 2 jpeg2000 codestreams are present in one frame. I re-reviewed this discussion and think I answered all concerns. I'm hesitant with patch v3 because I consider that touching frame_worker_thread for this feature is not so useful but I am ok with either patch v2 or v3. Thanks much, Jérôme On 20/02/2024 16:07, Jerome Martinez wrote: Attached is an updated version of the patch proposal. About the idea to keep separate fields in the output AVFrame, I note from the discussion that it is commonly accepted that up to now it is expected that the AVPacket contains what is in the MXF element and that the AVFrame contains a frame and never a field, and additionally I see in e.g. mpeg12dec.c that the decoder interleaves separate fields: mb_y <<= field_pic; if (s2->picture_structure == PICT_BOTTOM_FIELD) mb_y++; And mpegvideo_parser.c creates a AVPacket with both fields in AVPacket even if they are separated, this patch keeps the AVPacket from e.g. MXF with both fields in it and does something similar to what do other decoders with separate fields in the output AVFRame. About the detection of the 2 separated fields in 1 packet in the MXF file (I2 mode), it is doable in the example file provided in the first patch proposal to catch it by checking the essence label but other files I have don't have the specific essence label (they use the "undefined" essence label, legit) so IMO we should not rely on it and there is actually no practical advantage in catching that from the container. In practice this new patch proposal is slightly more complex, with one recursive call to jpeg2000_decode_frame() when there are 2 codestreams in 1 AVPacket, but it has a negligible performance impact (few comparisons and bool checks) when there is only one codestream in the AVPacket (the currently only supported method, remind that currently FFmpeg completely discards the 2nd codestream present in the AVPacket) and it relies on the current jpeg2000_read_main_headers() function for catching the end of the first codestream (safer than the quick find of EOC/SOC in the first version). It also changes the jpeg2000_decode_frame return value to the count of bytes parsed, it seems that it was what is expected but in practice it was not doing that, fixing the return value could be a separate patch if preferred. Jérôme On 02/02/2024 16:55, Jerome Martinez wrote: Before this patch, the FFmpeg MXF parser correctly detects content with 2 fields in 1 AVPacket as e.g. interlaced 720x486 but the FFmpeg JPEG 2000 decoder reads the JPEG 2000 SIZ header without understanding that the indicated height is the height of 1 field only so overwrites the frame size info with e.g. 720x243, and also completely discards the second frame, which lead to the decoding of only half of the stored content as "progressive" 720x243 flagged interlaced. Example file: https://www.digitizationguidelines.gov/guidelines/MXF_sampleFiles/RDD48-sample12-gf-jpeg2000-ntsc-4.2.zip Before this patch: Stream #0:0: Video: jpeg2000, yuv422p10le(bottom coded first (swapped)), 720x243, lossless, SAR 9:20 DAR 4:3, 29.97 tbr, 29.97 tbn, 29.97 tbc After this patch: Stream #0:0: Video: jpeg2000, yuv422p10le(bottom coded first (swapped)), 720x486, lossless, SAR 9:10 DAR 4:3, 29.97 fps, 29.97 tbr, 29.97 tbn ___ 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 0/5] replace scale2ref by scale=rw:rh
On 2024-04-24 04:21 pm, Niklas Haas wrote: As discussed in my previous series for fixing scale2ref[1], this filter is fundamentally broken, and the only real fix would be to switch to activate(), or ideally FFFrameSync. [1] https://ffmpeg.org//pipermail/ffmpeg-devel/2024-March/323382.html The main thing making this difficult is the fact that scale2ref also wants to output ref frames to its secondary output, which FFFrameSync does not support, and which is ultimately at least part of the root cause of trac #10795. Since this is in principle completely unnecessary (users can just 'split' the ref input and have it be consumed by vf_scale), and to make the design of this filter a bit more robust and maintainable, switch to an approach where vf_scale itself gains the ability to reference a secondary input stream, using the "ref_*" series of variables. This makes the current [i][ri]scale2ref[o][ro] equivalent to the only slightly more verbose [ri]split[t][ro]; [i][t]scale=rw:rh[o]. (And conversely, it is no longer necessary to use nullsink to consume an unused [ro]) In principle, a good idea, but how does this impact memory use and speed in the not-so-uncommon scenario where multiple overlay targets are scaled 2 ref and then overlaid e.g. in current flow: [a][base]scale2ref[a][ref]; [b][ref]scale2ref[b][ref[; [c][ref]scale2ref[c][ref[; [d][ref]scale2ref[d][ref[; [ref][a]overlay[ref]; [ref][b]overlay[ref]; [ref][c]overlay[ref]; [ref][d]overlay[ref]; in new flow: [base]split=5[base][refa][refb][refc][refd]; [a][refa]scale[a]; [b][refb]scale[b]; [c][refc]scale[c]; [d][refd]scale[d]; [base][a]overlay[outa]; [outa][b]overlay[outb]; [outb][c]overlay[outc]; [outc][d]overlay[out]; Regards, Gyan ___ 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 0/9] HTTP rate limiting and retry improvements
On Mon, 22 Apr 2024, Derek Buitenhuis wrote: This patch set adds support for properly handling HTTP 429 codes, and their rate limiting, which is widely used and is standardized. Changes since first set: * Added AVERROR_HTTP_TOO_MANY_REQUESTS top error_entries in error.c, per Andreas' review. * Made respect_retry_after unsigned and use strtoull, per James' review. * Added docs, as per Stefano's reviews./ * Added a new option to limit the total reconnect delay. * Unfortunate, but HTTP connection management is messy business. I had a look over this patchset, and I had a handful of minor comments, but overall, the patchset seems fine to me. Thanks! // 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 6/9] avformat/http: Add options to set the max number of connection retries
On Mon, 22 Apr 2024, Derek Buitenhuis wrote:
Not every use case benefits from setting retries in terms of the backoff.
Signed-off-by: Derek Buitenhuis
---
libavformat/http.c| 12 +---
libavformat/version.h | 2 +-
2 files changed, 10 insertions(+), 4 deletions(-)
diff --git a/libavformat/http.c b/libavformat/http.c
index 6927fea2fb..06bd3e340e 100644
--- a/libavformat/http.c
+++ b/libavformat/http.c
@@ -140,6 +140,7 @@ typedef struct HTTPContext {
uint64_t filesize_from_content_range;
int respect_retry_after;
unsigned int retry_after;
+int reconnect_max_retries;
} HTTPContext;
#define OFFSET(x) offsetof(HTTPContext, x)
@@ -178,6 +179,7 @@ static const AVOption options[] = {
{ "reconnect_on_http_error", "list of http status codes to reconnect on",
OFFSET(reconnect_on_http_error), AV_OPT_TYPE_STRING, { .str = NULL }, 0, 0, D },
{ "reconnect_streamed", "auto reconnect streamed / non seekable streams",
OFFSET(reconnect_streamed), AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0, 1, D },
{ "reconnect_delay_max", "max reconnect delay in seconds after which to give
up", OFFSET(reconnect_delay_max), AV_OPT_TYPE_INT, { .i64 = 120 }, 0, UINT_MAX/1000/1000, D },
+{ "reconnect_max_retries", "the max number of times to retry a
connection", OFFSET(reconnect_max_retries), AV_OPT_TYPE_INT, { .i64 = -1 }, -1, INT_MAX, D },
{ "respect_retry_after", "respect the Retry-After header when retrying
connections", OFFSET(respect_retry_after), AV_OPT_TYPE_BOOL, { .i64 = 1 }, 0, 1, D },
{ "listen", "listen on HTTP", OFFSET(listen), AV_OPT_TYPE_INT, { .i64 = 0
}, 0, 2, D | E },
{ "resource", "The resource requested by a client", OFFSET(resource),
AV_OPT_TYPE_STRING, { .str = NULL }, 0, 0, E },
@@ -359,7 +361,7 @@ static int http_open_cnx(URLContext *h, AVDictionary
**options)
{
HTTPAuthType cur_auth_type, cur_proxy_auth_type;
HTTPContext *s = h->priv_data;
-int ret, auth_attempts = 0, redirects = 0;
+int ret, conn_attempts = 1, auth_attempts = 0, redirects = 0;
int reconnect_delay = 0;
uint64_t off;
char *cached;
@@ -386,7 +388,8 @@ redo:
ret = http_open_cnx_internal(h, options);
if (ret < 0) {
if (!http_should_reconnect(s, ret) ||
-reconnect_delay > s->reconnect_delay_max)
+reconnect_delay > s->reconnect_delay_max ||
+(s->reconnect_max_retries >= 0 && conn_attempts >
s->reconnect_max_retries))
goto fail;
if (s->respect_retry_after && s->retry_after > 0) {
@@ -401,6 +404,7 @@ redo:
if (ret != AVERROR(ETIMEDOUT))
goto fail;
reconnect_delay = 1 + 2 * reconnect_delay;
+conn_attempts++;
/* restore the offset (http_connect resets it) */
s->off = off;
@@ -1706,6 +1710,7 @@ static int http_read_stream(URLContext *h, uint8_t *buf,
int size)
int err, read_ret;
int64_t seek_ret;
int reconnect_delay = 0;
+int conn_attempt = 1;
Minor inconsistency; the corresponding variable in the other function was
called conn_attempts, as a plural.
// 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 4/9] avformat/http: Add support for Retry-After header
On Mon, 22 Apr 2024, Derek Buitenhuis wrote:
429 and 503 codes can, and often do (e.g. all Google Cloud
Storage URLs can), return a Retry-After header with the error,
indicating how long to wait, in seconds, before retrying again.
If it is not respected by, for example, using our default backoff
stratetgy instead, chances of success are very unlikely.
This adds an AVOption to respect that header.
Signed-off-by: Derek Buitenhuis
---
libavformat/http.c| 12
libavformat/version.h | 2 +-
2 files changed, 13 insertions(+), 1 deletion(-)
Is this feature standardized in a RFC, or is it some other spec somewhere?
I think it would be nice with a link to a spec in the commit message here.
diff --git a/libavformat/http.c b/libavformat/http.c
index e7603037f4..5ed481b63a 100644
--- a/libavformat/http.c
+++ b/libavformat/http.c
@@ -138,6 +138,8 @@ typedef struct HTTPContext {
char *new_location;
AVDictionary *redirect_cache;
uint64_t filesize_from_content_range;
+int respect_retry_after;
+unsigned int retry_after;
} HTTPContext;
#define OFFSET(x) offsetof(HTTPContext, x)
@@ -176,6 +178,7 @@ static const AVOption options[] = {
{ "reconnect_on_http_error", "list of http status codes to reconnect on",
OFFSET(reconnect_on_http_error), AV_OPT_TYPE_STRING, { .str = NULL }, 0, 0, D },
{ "reconnect_streamed", "auto reconnect streamed / non seekable streams",
OFFSET(reconnect_streamed), AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0, 1, D },
{ "reconnect_delay_max", "max reconnect delay in seconds after which to give
up", OFFSET(reconnect_delay_max), AV_OPT_TYPE_INT, { .i64 = 120 }, 0, UINT_MAX/1000/1000, D },
+{ "respect_retry_after", "respect the Retry-After header when retrying
connections", OFFSET(respect_retry_after), AV_OPT_TYPE_BOOL, { .i64 = 1 }, 0, 1, D },
{ "listen", "listen on HTTP", OFFSET(listen), AV_OPT_TYPE_INT, { .i64 = 0
}, 0, 2, D | E },
{ "resource", "The resource requested by a client", OFFSET(resource),
AV_OPT_TYPE_STRING, { .str = NULL }, 0, 0, E },
{ "reply_code", "The http status code to return to a client",
OFFSET(reply_code), AV_OPT_TYPE_INT, { .i64 = 200}, INT_MIN, 599, E},
@@ -386,6 +389,13 @@ redo:
reconnect_delay > s->reconnect_delay_max)
goto fail;
+if (s->respect_retry_after && s->retry_after > 0) {
+reconnect_delay = s->retry_after;
It'd be nice with a comment to clarify the units of both values here,
which apparently both happen to be integer seconds?
+if (reconnect_delay > s->reconnect_delay_max)
+goto fail;
+s->retry_after = 0;
+}
+
av_log(h, AV_LOG_WARNING, "Will reconnect at %"PRIu64" in %d
second(s).\n", off, reconnect_delay);
ret = ff_network_sleep_interruptible(1000U * 1000 * reconnect_delay,
>interrupt_callback);
if (ret != AVERROR(ETIMEDOUT))
@@ -1231,6 +1241,8 @@ static int process_line(URLContext *h, char *line, int
line_count, int *parsed_h
parse_expires(s, p);
} else if (!av_strcasecmp(tag, "Cache-Control")) {
parse_cache_control(s, p);
+} else if (!av_strcasecmp(tag, "Retry-After")) {
+s->retry_after = strtoul(p, NULL, 10);
Can you add a comment here, to clarify what unit the value is expressed
in?
// 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".
[FFmpeg-devel] [PATCH 5/5] avfilter/scale2ref: deprecate in favor of scale=rw:rh
From: Niklas Haas
And remove it from the documentation.
---
Changelog | 1 +
doc/filters.texi | 73 --
libavfilter/vf_scale.c | 3 ++
3 files changed, 4 insertions(+), 73 deletions(-)
diff --git a/Changelog b/Changelog
index e821e5ac74..e827208439 100644
--- a/Changelog
+++ b/Changelog
@@ -8,6 +8,7 @@ version :
- LC3/LC3plus demuxer and muxer
- pad_vaapi, drawbox_vaapi filters
- vf_scale supports secondary ref input and framesync options
+- vf_scale2ref deprecated
version 7.0:
diff --git a/doc/filters.texi b/doc/filters.texi
index cf884568b0..5198f14f28 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -21590,79 +21590,6 @@ Scale a logo to 1/10th the height of a video, while
preserving its display aspec
@end example
@end itemize
-@section scale2ref
-
-Scale (resize) the input video, based on a reference video.
-
-See the scale filter for available options, scale2ref supports the same but
-uses the reference video instead of the main input as basis. scale2ref also
-supports the following additional constants for the @option{w} and
-@option{h} options:
-
-@table @var
-@item main_w
-@item main_h
-The main input video's width and height
-
-@item main_a
-The same as @var{main_w} / @var{main_h}
-
-@item main_sar
-The main input video's sample aspect ratio
-
-@item main_dar, mdar
-The main input video's display aspect ratio. Calculated from
-@code{(main_w / main_h) * main_sar}.
-
-@item main_hsub
-@item main_vsub
-The main input video's horizontal and vertical chroma subsample values.
-For example for the pixel format "yuv422p" @var{hsub} is 2 and @var{vsub}
-is 1.
-
-@item main_n
-The (sequential) number of the main input frame, starting from 0.
-Only available with @code{eval=frame}.
-
-@item main_t
-The presentation timestamp of the main input frame, expressed as a number of
-seconds. Only available with @code{eval=frame}.
-
-@item main_pos
-The position (byte offset) of the frame in the main input stream, or NaN if
-this information is unavailable and/or meaningless (for example in case of
synthetic video).
-Only available with @code{eval=frame}.
-@end table
-
-@subsection Examples
-
-@itemize
-@item
-Scale a subtitle stream (b) to match the main video (a) in size before
overlaying
-@example
-'scale2ref[b][a];[a][b]overlay'
-@end example
-
-@item
-Scale a logo to 1/10th the height of a video, while preserving its display
aspect ratio.
-@example
-[logo-in][video-in]scale2ref=w=oh*mdar:h=ih/10[logo-out][video-out]
-@end example
-@end itemize
-
-@subsection Commands
-
-This filter supports the following commands:
-@table @option
-@item width, w
-@item height, h
-Set the output video dimension expression.
-The command accepts the same syntax of the corresponding option.
-
-If the specified expression is not valid, it is kept at its current
-value.
-@end table
-
@section scale2ref_npp
Use the NVIDIA Performance Primitives (libnpp) to scale (resize) the input
diff --git a/libavfilter/vf_scale.c b/libavfilter/vf_scale.c
index f174651333..bc53571c1c 100644
--- a/libavfilter/vf_scale.c
+++ b/libavfilter/vf_scale.c
@@ -368,6 +368,9 @@ static av_cold int init(AVFilterContext *ctx)
int64_t threads;
int ret;
+if (ctx->filter == _vf_scale2ref)
+av_log(ctx, AV_LOG_WARNING, "scale2ref is deprecated, use scale=rw:rh
instead\n");
+
if (scale->size_str && (scale->w_expr || scale->h_expr)) {
av_log(ctx, AV_LOG_ERROR,
"Size and width/height expressions cannot be set at the same
time.\n");
--
2.44.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] aacdec: avoid generating unused code when either implementation is disabled
Minor optimization to remove extra branches.
We need to include the header for xHE anyway, which is float-only.
>From 54f53fb1c0694bf2777a1eefb1f585a804d56978 Mon Sep 17 00:00:00 2001
From: Lynne
Date: Wed, 24 Apr 2024 13:01:14 +0200
Subject: [PATCH] aacdec: avoid generating unused code when either
implementation is disabled
Minor optimization to remove extra branches.
We need to include the header for xHE anyway, which is float-only.
---
libavcodec/aac/aacdec.c | 22 ++
1 file changed, 14 insertions(+), 8 deletions(-)
diff --git a/libavcodec/aac/aacdec.c b/libavcodec/aac/aacdec.c
index 4a29c1b092..72f2d7e7ba 100644
--- a/libavcodec/aac/aacdec.c
+++ b/libavcodec/aac/aacdec.c
@@ -33,6 +33,8 @@
* for which we need this to be defined for them to work as expected. */
#define USE_FIXED 1
+#include "config_components.h"
+
#include
#include
@@ -1312,9 +1314,9 @@ static void decode_ltp(AACDecContext *ac, LongTermPrediction *ltp,
int sfb;
ltp->lag = get_bits(gb, 11);
-if (ac->is_fixed)
+if (CONFIG_AAC_FIXED_DECODER && ac->is_fixed)
ltp->coef_fixed = Q30(ff_ltp_coef[get_bits(gb, 3)]);
-else
+else if (CONFIG_AAC_DECODER)
ltp->coef = ff_ltp_coef[get_bits(gb, 3)];
for (sfb = 0; sfb < FFMIN(max_sfb, MAX_LTP_LONG_SFB); sfb++)
@@ -1623,9 +1625,9 @@ static int decode_tns(AACDecContext *ac, TemporalNoiseShaping *tns,
tmp2_idx = 2 * coef_compress + coef_res;
for (i = 0; i < tns->order[w][filt]; i++) {
-if (ac->is_fixed)
+if (CONFIG_AAC_FIXED_DECODER && ac->is_fixed)
tns->coef_fixed[w][filt][i] = Q31(ff_tns_tmp2_map[tmp2_idx][get_bits(gb, coef_len)]);
-else
+else if (CONFIG_AAC_DECODER)
tns->coef[w][filt][i] = ff_tns_tmp2_map[tmp2_idx][get_bits(gb, coef_len)];
}
}
@@ -1974,9 +1976,9 @@ static int decode_extension_payload(AACDecContext *ac, GetBitContext *gb, int cn
ac->avctx->profile = AV_PROFILE_AAC_HE;
}
-if (ac->is_fixed)
+if (CONFIG_AAC_FIXED_DECODER && ac->is_fixed)
res = ff_aac_sbr_decode_extension_fixed(ac, che, gb, crc_flag, cnt, elem_type);
-else
+else if (CONFIG_AAC_DECODER)
res = ff_aac_sbr_decode_extension(ac, che, gb, crc_flag, cnt, elem_type);
@@ -2087,11 +2089,11 @@ static void spectral_to_sample(AACDecContext *ac, int samples)
ac->dsp.update_ltp(ac, >ch[1]);
}
if (ac->oc[1].m4ac.sbr > 0) {
-if (ac->is_fixed)
+if (CONFIG_AAC_FIXED_DECODER && ac->is_fixed)
ff_aac_sbr_apply_fixed(ac, che, type,
(void *)che->ch[0].output,
(void *)che->ch[1].output);
-else
+else if (CONFIG_AAC_DECODER)
ff_aac_sbr_apply(ac, che, type,
(void *)che->ch[0].output,
(void *)che->ch[1].output);
@@ -2550,6 +2552,7 @@ static const AVClass decoder_class = {
.version= LIBAVUTIL_VERSION_INT,
};
+#if CONFIG_AAC_DECODER
const FFCodec ff_aac_decoder = {
.p.name = "aac",
CODEC_LONG_NAME("AAC (Advanced Audio Coding)"),
@@ -2569,7 +2572,9 @@ const FFCodec ff_aac_decoder = {
.flush = flush,
.p.profiles = NULL_IF_CONFIG_SMALL(ff_aac_profiles),
};
+#endif
+#if CONFIG_AAC_FIXED_DECODER
const FFCodec ff_aac_fixed_decoder = {
.p.name = "aac_fixed",
CODEC_LONG_NAME("AAC (Advanced Audio Coding)"),
@@ -2589,3 +2594,4 @@ const FFCodec ff_aac_fixed_decoder = {
.p.profiles = NULL_IF_CONFIG_SMALL(ff_aac_profiles),
.flush = flush,
};
+#endif
--
2.43.0.381.gb435a96ce8
___
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 4/5] fate/scale2ref_keep_aspect: switch to vf_scale ref_*
From: Niklas Haas --- tests/filtergraphs/scale2ref_keep_aspect | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/tests/filtergraphs/scale2ref_keep_aspect b/tests/filtergraphs/scale2ref_keep_aspect index f407460ec7..00b04fc3d1 100644 --- a/tests/filtergraphs/scale2ref_keep_aspect +++ b/tests/filtergraphs/scale2ref_keep_aspect @@ -1,5 +1,4 @@ sws_flags=+accurate_rnd+bitexact; testsrc=size=320x240 [main]; testsrc=size=640x360 [ref]; -[main][ref] scale2ref=iw/4:ow/mdar [main][ref]; -[ref] nullsink +[main][ref] scale=rw/4:ow/dar [main] -- 2.44.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 3/5] avfilter/vf_scale: add optional "ref" input
From: Niklas Haas
This is automatically enabled if the width/height expressions reference
any ref_* variable. This will ultimately serve as a more principled
replacement for the fundamentally broken scale2ref.
See-Also: https://trac.ffmpeg.org/ticket/10795
---
Changelog | 1 +
doc/filters.texi | 26
libavfilter/vf_scale.c | 132 -
3 files changed, 156 insertions(+), 3 deletions(-)
diff --git a/Changelog b/Changelog
index 8db14f02b4..e821e5ac74 100644
--- a/Changelog
+++ b/Changelog
@@ -7,6 +7,7 @@ version :
- ffmpeg CLI filtergraph chaining
- LC3/LC3plus demuxer and muxer
- pad_vaapi, drawbox_vaapi filters
+- vf_scale supports secondary ref input and framesync options
version 7.0:
diff --git a/doc/filters.texi b/doc/filters.texi
index f20b72ab96..cf884568b0 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -21562,8 +21562,34 @@ The position (byte offset) of the frame in the input
stream, or NaN if
this information is unavailable and/or meaningless (for example in case of
synthetic video).
Only available with @code{eval=frame}.
Deprecated, do not use.
+
+@item ref_w, rw
+@item ref_h, rh
+@item ref_a
+@item ref_dar, rdar
+@item ref_n
+@item ref_t
+@item ref_pos
+Eqvuialent to the above, but for a second reference input. If any of these
+variables are present, this filter accepts two inputs.
@end table
+@subsection Examples
+
+@itemize
+@item
+Scale a subtitle stream (sub) to match the main video (main) in size before
overlaying
+@example
+'[main]split[a][b]; [ref][a]scale=rw:rh[c]; [b][c]overlay'
+@end example
+
+@item
+Scale a logo to 1/10th the height of a video, while preserving its display
aspect ratio.
+@example
+[logo-in][video-in]scale=w=oh*dar:h=rh/10[logo-out]
+@end example
+@end itemize
+
@section scale2ref
Scale (resize) the input video, based on a reference video.
diff --git a/libavfilter/vf_scale.c b/libavfilter/vf_scale.c
index a986dc97ae..f174651333 100644
--- a/libavfilter/vf_scale.c
+++ b/libavfilter/vf_scale.c
@@ -59,6 +59,17 @@ static const char *const var_names[] = {
#if FF_API_FRAME_PKT
"pos",
#endif
+"ref_w", "rw",
+"ref_h", "rh",
+"ref_a",
+"ref_sar",
+"ref_dar", "rdar",
+"ref_hsub",
+"ref_vsub",
+"ref_n",
+"ref_t",
+"ref_pos",
+/* Legacy variables for scale2ref */
"main_w",
"main_h",
"main_a",
@@ -89,6 +100,16 @@ enum var_name {
#if FF_API_FRAME_PKT
VAR_POS,
#endif
+VAR_REF_W, VAR_RW,
+VAR_REF_H, VAR_RH,
+VAR_REF_A,
+VAR_REF_SAR,
+VAR_REF_DAR, VAR_RDAR,
+VAR_REF_HSUB,
+VAR_REF_VSUB,
+VAR_REF_N,
+VAR_REF_T,
+VAR_REF_POS,
VAR_S2R_MAIN_W,
VAR_S2R_MAIN_H,
VAR_S2R_MAIN_A,
@@ -131,6 +152,7 @@ typedef struct ScaleContext {
int input_is_pal; ///< set to 1 if the input format is paletted
int output_is_pal; ///< set to 1 if the output format is paletted
int interlaced;
+int uses_ref;
char *w_expr; ///< width expression string
char *h_expr; ///< height expression string
@@ -190,6 +212,38 @@ static int check_exprs(AVFilterContext *ctx)
av_log(ctx, AV_LOG_WARNING, "Circular references detected for width
'%s' and height '%s' - possibly invalid.\n", scale->w_expr, scale->h_expr);
}
+if (vars_w[VAR_REF_W]|| vars_h[VAR_REF_W]||
+vars_w[VAR_RW] || vars_h[VAR_RW] ||
+vars_w[VAR_REF_H]|| vars_h[VAR_REF_H]||
+vars_w[VAR_RH] || vars_h[VAR_RH] ||
+vars_w[VAR_REF_A]|| vars_h[VAR_REF_A]||
+vars_w[VAR_REF_SAR] || vars_h[VAR_REF_SAR] ||
+vars_w[VAR_REF_DAR] || vars_h[VAR_REF_DAR] ||
+vars_w[VAR_RDAR] || vars_h[VAR_RDAR] ||
+vars_w[VAR_REF_HSUB] || vars_h[VAR_REF_HSUB] ||
+vars_w[VAR_REF_VSUB] || vars_h[VAR_REF_VSUB] ||
+vars_w[VAR_REF_N]|| vars_h[VAR_REF_N]||
+vars_w[VAR_REF_T]|| vars_h[VAR_REF_T]||
+vars_w[VAR_REF_POS] || vars_h[VAR_REF_POS]) {
+scale->uses_ref = 1;
+}
+
+if (ctx->filter != _vf_scale2ref &&
+(vars_w[VAR_S2R_MAIN_W]|| vars_h[VAR_S2R_MAIN_W]||
+ vars_w[VAR_S2R_MAIN_H]|| vars_h[VAR_S2R_MAIN_H]||
+ vars_w[VAR_S2R_MAIN_A]|| vars_h[VAR_S2R_MAIN_A]||
+ vars_w[VAR_S2R_MAIN_SAR] || vars_h[VAR_S2R_MAIN_SAR] ||
+ vars_w[VAR_S2R_MAIN_DAR] || vars_h[VAR_S2R_MAIN_DAR] ||
+ vars_w[VAR_S2R_MDAR] || vars_h[VAR_S2R_MDAR] ||
+ vars_w[VAR_S2R_MAIN_HSUB] || vars_h[VAR_S2R_MAIN_HSUB] ||
+ vars_w[VAR_S2R_MAIN_VSUB] || vars_h[VAR_S2R_MAIN_VSUB] ||
+ vars_w[VAR_S2R_MAIN_N]|| vars_h[VAR_S2R_MAIN_N]||
+ vars_w[VAR_S2R_MAIN_T]|| vars_h[VAR_S2R_MAIN_T]||
+ vars_w[VAR_S2R_MAIN_POS] || vars_h[VAR_S2R_MAIN_POS]) ) {
+av_log(ctx, AV_LOG_ERROR, "Expressions with
[FFmpeg-devel] [PATCH 2/5] avfilter/vf_scale: switch to FFFrameSync
From: Niklas Haas
Preliminary commit, in anticipation of adding support for multiple
inputs (with proper synchronization and activate() callback).
---
doc/filters.texi | 4 +--
libavfilter/vf_scale.c | 65 +++---
2 files changed, 63 insertions(+), 6 deletions(-)
diff --git a/doc/filters.texi b/doc/filters.texi
index fc813f12c1..f20b72ab96 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -20989,8 +20989,8 @@ the next filter, the scale filter will convert the
input to the
requested format.
@subsection Options
-The filter accepts the following options, or any of the options
-supported by the libswscale scaler.
+The filter accepts the following options, any of the options supported
+by the libswscale scaler, as well as any of the @ref{framesync} options.
See @ref{scaler_options,,the ffmpeg-scaler manual,ffmpeg-scaler} for
the complete list of scaler options.
diff --git a/libavfilter/vf_scale.c b/libavfilter/vf_scale.c
index 1c07daeddf..a986dc97ae 100644
--- a/libavfilter/vf_scale.c
+++ b/libavfilter/vf_scale.c
@@ -29,6 +29,7 @@
#include "avfilter.h"
#include "formats.h"
+#include "framesync.h"
#include "internal.h"
#include "scale_eval.h"
#include "video.h"
@@ -113,6 +114,7 @@ typedef struct ScaleContext {
struct SwsContext *isws[2]; ///< software scaler context for interlaced
material
// context used for forwarding options to sws
struct SwsContext *sws_opts;
+FFFrameSync fs;
/**
* New dimensions. Special values are:
@@ -287,6 +289,8 @@ static av_cold int preinit(AVFilterContext *ctx)
if (ret < 0)
return ret;
+ff_framesync_preinit(>fs);
+
return 0;
}
@@ -302,6 +306,8 @@ static const int sws_colorspaces[] = {
-1
};
+static int do_scale(FFFrameSync *fs);
+
static av_cold int init(AVFilterContext *ctx)
{
ScaleContext *scale = ctx->priv;
@@ -388,6 +394,7 @@ static av_cold void uninit(AVFilterContext *ctx)
av_expr_free(scale->w_pexpr);
av_expr_free(scale->h_pexpr);
scale->w_pexpr = scale->h_pexpr = NULL;
+ff_framesync_uninit(>fs);
sws_freeContext(scale->sws_opts);
sws_freeContext(scale->sws);
sws_freeContext(scale->isws[0]);
@@ -677,6 +684,21 @@ static int config_props(AVFilterLink *outlink)
flags_val);
av_freep(_val);
+if (ctx->filter != _vf_scale2ref) {
+ret = ff_framesync_init(>fs, ctx, ctx->nb_inputs);
+if (ret < 0)
+return ret;
+scale->fs.on_event= do_scale;
+scale->fs.in[0].time_base = ctx->inputs[0]->time_base;
+scale->fs.in[0].sync = 1;
+scale->fs.in[0].before= EXT_STOP;
+scale->fs.in[0].after = EXT_STOP;
+
+ret = ff_framesync_configure(>fs);
+if (ret < 0)
+return ret;
+}
+
return 0;
fail:
@@ -894,6 +916,26 @@ scale:
return ret;
}
+static int do_scale(FFFrameSync *fs)
+{
+AVFilterContext *ctx = fs->parent;
+AVFilterLink *outlink = ctx->outputs[0];
+AVFrame *in, *out;
+int ret;
+
+ret = ff_framesync_get_frame(fs, 0, , 1);
+if (ret < 0)
+return ret;
+
+ret = scale_frame(ctx->inputs[0], in, );
+if (out) {
+out->pts = av_rescale_q(fs->pts, fs->time_base, outlink->time_base);
+return ff_filter_frame(outlink, out);
+}
+
+return ret;
+}
+
static int filter_frame(AVFilterLink *link, AVFrame *in)
{
AVFilterContext *ctx = link->dst;
@@ -972,11 +1014,24 @@ static int process_command(AVFilterContext *ctx, const
char *cmd, const char *ar
return ret;
}
+static int activate(AVFilterContext *ctx)
+{
+ScaleContext *scale = ctx->priv;
+return ff_framesync_activate(>fs);
+}
+
static const AVClass *child_class_iterate(void **iter)
{
-const AVClass *c = *iter ? NULL : sws_get_class();
-*iter = (void*)(uintptr_t)c;
-return c;
+switch ((uintptr_t) *iter) {
+case 0:
+*iter = (void*)(uintptr_t) 1;
+return sws_get_class();
+case 1:
+*iter = (void*)(uintptr_t) 2;
+return _framesync_class;
+}
+
+return NULL;
}
static void *child_next(void *obj, void *prev)
@@ -984,6 +1039,8 @@ static void *child_next(void *obj, void *prev)
ScaleContext *s = obj;
if (!prev)
return s->sws_opts;
+if (prev == s->sws_opts)
+return >fs;
return NULL;
}
@@ -1051,7 +1108,6 @@ static const AVFilterPad avfilter_vf_scale_inputs[] = {
{
.name = "default",
.type = AVMEDIA_TYPE_VIDEO,
-.filter_frame = filter_frame,
},
};
@@ -1074,6 +1130,7 @@ const AVFilter ff_vf_scale = {
FILTER_INPUTS(avfilter_vf_scale_inputs),
FILTER_OUTPUTS(avfilter_vf_scale_outputs),
FILTER_QUERY_FUNC(query_formats),
+.activate= activate,
.process_command = process_command,
};
--
2.44.0
___
ffmpeg-devel mailing list
[FFmpeg-devel] [PATCH 1/5] avfilter/framesync: make framesync_class un-static
From: Niklas Haas
And rename to ff_framesync_class. More convenient for downstream users.
---
libavfilter/framesync.c | 6 +++---
libavfilter/framesync.h | 1 +
2 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/libavfilter/framesync.c b/libavfilter/framesync.c
index 1afd70ab21..a691136f34 100644
--- a/libavfilter/framesync.c
+++ b/libavfilter/framesync.c
@@ -51,7 +51,7 @@ static const AVOption framesync_options[] = {
0, AV_OPT_TYPE_CONST, { .i64 = TS_NEAREST }, .flags = FLAGS, .unit
= "ts_sync_mode" },
{ NULL }
};
-static const AVClass framesync_class = {
+const AVClass ff_framesync_class = {
.version = LIBAVUTIL_VERSION_INT,
.class_name= "framesync",
.item_name = framesync_name,
@@ -62,7 +62,7 @@ static const AVClass framesync_class = {
const AVClass *ff_framesync_child_class_iterate(void **iter)
{
-const AVClass *c = *iter ? NULL : _class;
+const AVClass *c = *iter ? NULL : _framesync_class;
*iter = (void *)(uintptr_t)c;
return c;
}
@@ -79,7 +79,7 @@ void ff_framesync_preinit(FFFrameSync *fs)
{
if (fs->class)
return;
-fs->class = _class;
+fs->class = _framesync_class;
av_opt_set_defaults(fs);
}
diff --git a/libavfilter/framesync.h b/libavfilter/framesync.h
index 233f50a0eb..130d067bae 100644
--- a/libavfilter/framesync.h
+++ b/libavfilter/framesync.h
@@ -316,6 +316,7 @@ int ff_framesync_dualinput_get(FFFrameSync *fs, AVFrame
**f0, AVFrame **f1);
int ff_framesync_dualinput_get_writable(FFFrameSync *fs, AVFrame **f0, AVFrame
**f1);
const AVClass *ff_framesync_child_class_iterate(void **iter);
+extern const AVClass ff_framesync_class;
#define FRAMESYNC_DEFINE_PURE_CLASS(name, desc, func_prefix, options) \
static const AVClass name##_class = { \
--
2.44.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 0/5] replace scale2ref by scale=rw:rh
As discussed in my previous series for fixing scale2ref[1], this filter is fundamentally broken, and the only real fix would be to switch to activate(), or ideally FFFrameSync. [1] https://ffmpeg.org//pipermail/ffmpeg-devel/2024-March/323382.html The main thing making this difficult is the fact that scale2ref also wants to output ref frames to its secondary output, which FFFrameSync does not support, and which is ultimately at least part of the root cause of trac #10795. Since this is in principle completely unnecessary (users can just 'split' the ref input and have it be consumed by vf_scale), and to make the design of this filter a bit more robust and maintainable, switch to an approach where vf_scale itself gains the ability to reference a secondary input stream, using the "ref_*" series of variables. This makes the current [i][ri]scale2ref[o][ro] equivalent to the only slightly more verbose [ri]split[t][ro]; [i][t]scale=rw:rh[o]. (And conversely, it is no longer necessary to use nullsink to consume an unused [ro]) Incidentally, I think it would be nice if lavfi could *automatically* split filter links referenced multiple times, so we could just write e.g. [i][ri]scale=rw:rh[o]; [ri][o]overlay[out] and have it work. Maybe I'll try getting that to work, next. Either way, after the deprecation period has elapsed, we can delete scale2ref from the codebase in order to make vf_scale.c IMHO significantly simpler versus the status quo. ___ 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] opusdsp: add ability to modify deemphasis constant
Apr 24, 2024, 10:54 by d...@lynne.ee:
> xHE-AAC relies on the same postfilter mechanism
> that Opus uses to improve clarity (albeit with a steeper
> deemphasis filter).
>
> The code to apply it is identical, it's still just a
> simple IIR low-pass filter. This commit makes it possible
> to use alternative constants.
>
> Version 2 changes:
> Move the deemphasis constant table to opustab.c and
> document its values better.
>
v3 attached, forgot to port the native opus encoder.
>From 22fa7632e843785600b3ba3f56e476eed65e42f0 Mon Sep 17 00:00:00 2001
From: Lynne
Date: Mon, 29 Jan 2024 04:31:43 +0100
Subject: [PATCH v3] opusdsp: add ability to modify deemphasis constant
xHE-AAC relies on the same postfilter mechanism
that Opus uses to improve clarity (albeit with a steeper
deemphasis filter).
The code to apply it is identical, it's still just a
simple IIR low-pass filter. This commit makes it possible
to use alternative constants.
---
libavcodec/aarch64/opusdsp_init.c | 2 +-
libavcodec/aarch64/opusdsp_neon.S | 28 +---
libavcodec/opusdec_celt.c | 6 --
libavcodec/opusdsp.c | 6 --
libavcodec/opusdsp.h | 4 +---
libavcodec/opusenc.c | 5 +++--
libavcodec/opustab.c | 28
libavcodec/opustab.h | 2 ++
libavcodec/x86/opusdsp.asm| 9 +++--
libavcodec/x86/opusdsp_init.c | 2 +-
10 files changed, 52 insertions(+), 40 deletions(-)
diff --git a/libavcodec/aarch64/opusdsp_init.c b/libavcodec/aarch64/opusdsp_init.c
index bb6d71b66b..a727006593 100644
--- a/libavcodec/aarch64/opusdsp_init.c
+++ b/libavcodec/aarch64/opusdsp_init.c
@@ -23,7 +23,7 @@
#include "libavcodec/opusdsp.h"
void ff_opus_postfilter_neon(float *data, int period, float *gains, int len);
-float ff_opus_deemphasis_neon(float *out, float *in, float coeff, int len);
+float ff_opus_deemphasis_neon(float *out, float *in, float coeff, const float *weights, int len);
av_cold void ff_opus_dsp_init_aarch64(OpusDSP *ctx)
{
diff --git a/libavcodec/aarch64/opusdsp_neon.S b/libavcodec/aarch64/opusdsp_neon.S
index e933151ab4..253825aa61 100644
--- a/libavcodec/aarch64/opusdsp_neon.S
+++ b/libavcodec/aarch64/opusdsp_neon.S
@@ -18,29 +18,11 @@
#include "libavutil/aarch64/asm.S"
- // 0.85..^10.85..^20.85..^30.85..^4
-const tab_st, align=4
-.word 0x3f599a00, 0x3f38f671, 0x3f1d382a, 0x3f05a32f
-endconst
-const tab_x0, align=4
-.word 0x0,0x3f599a00, 0x3f38f671, 0x3f1d382a
-endconst
-const tab_x1, align=4
-.word 0x0,0x0,0x3f599a00, 0x3f38f671
-endconst
-const tab_x2, align=4
-.word 0x0,0x0,0x0,0x3f599a00
-endconst
-
function ff_opus_deemphasis_neon, export=1
-movrel x4, tab_st
-ld1 {v4.4s}, [x4]
-movrel x4, tab_x0
-ld1 {v5.4s}, [x4]
-movrel x4, tab_x1
-ld1 {v6.4s}, [x4]
-movrel x4, tab_x2
-ld1 {v7.4s}, [x4]
+ld1 {v4.4s}, [x2], #16
+ld1 {v5.4s}, [x2], #16
+ld1 {v6.4s}, [x2], #16
+ld1 {v7.4s}, [x2]
fmulv0.4s, v4.4s, v0.s[0]
@@ -63,7 +45,7 @@ function ff_opus_deemphasis_neon, export=1
st1 {v1.4s, v2.4s}, [x0], #32
fmulv0.4s, v4.4s, v2.s[3]
-subsw2, w2, #8
+subsw3, w3, #8
b.gt1b
mov s0, v2.s[3]
diff --git a/libavcodec/opusdec_celt.c b/libavcodec/opusdec_celt.c
index fd8e9929e9..b19342337d 100644
--- a/libavcodec/opusdec_celt.c
+++ b/libavcodec/opusdec_celt.c
@@ -460,7 +460,9 @@ int ff_celt_decode_frame(CeltFrame *f, OpusRangeCoder *rc,
/* deemphasis */
block->emph_coeff = f->opusdsp.deemphasis(output[i],
>buf[1024 - frame_size],
- block->emph_coeff, frame_size);
+ block->emph_coeff,
+ ff_opus_deemph_weights,
+ frame_size);
}
if (channels == 1)
@@ -516,7 +518,7 @@ void ff_celt_flush(CeltFrame *f)
* a lesser discontinuity when seeking.
* The deemphasis functions differ from libopus in that they require
* an initial state divided by the coefficient. */
-block->emph_coeff = 0.0f / CELT_EMPH_COEFF;
+block->emph_coeff = 0.0f / ff_opus_deemph_weights[0];
}
f->seed = 0;
diff --git a/libavcodec/opusdsp.c b/libavcodec/opusdsp.c
index 0764d712e4..e61cc36098 100644
--- a/libavcodec/opusdsp.c
+++ b/libavcodec/opusdsp.c
@@ -18,6 +18,7 @@
#include "config.h"
#include "libavutil/attributes.h"
+#include
Re: [FFmpeg-devel] [PATCH v2 2/9] avformat/http: Use AVERROR_HTTP_TOO_MANY_REQUESTS
On Mon, 22 Apr 2024, Derek Buitenhuis wrote: Added in thep previous commit. Signed-off-by: Derek Buitenhuis --- libavformat/http.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/libavformat/http.c b/libavformat/http.c index ed20359552..bbace2694f 100644 --- a/libavformat/http.c +++ b/libavformat/http.c @@ -286,6 +286,7 @@ static int http_should_reconnect(HTTPContext *s, int err) case AVERROR_HTTP_UNAUTHORIZED: case AVERROR_HTTP_FORBIDDEN: case AVERROR_HTTP_NOT_FOUND: +case AVERROR_HTTP_TOO_MANY_REQUESTS: case AVERROR_HTTP_OTHER_4XX: status_group = "4xx"; break; @@ -522,6 +523,7 @@ int ff_http_averror(int status_code, int default_averror) case 401: return AVERROR_HTTP_UNAUTHORIZED; case 403: return AVERROR_HTTP_FORBIDDEN; case 404: return AVERROR_HTTP_NOT_FOUND; +case 429: return AVERROR_HTTP_TOO_MANY_REQUESTS; default: break; } if (status_code >= 400 && status_code <= 499) @@ -558,6 +560,10 @@ static int http_write_reply(URLContext* h, int status_code) reply_code = 404; reply_text = "Not Found"; break; +case 429: +reply_code = 429; +reply_text = "Too Many Requests"; +break; case 200: This function seems to handle both the literal status codes, like 429, and also AVERROR style error codes, as when called from handle_http_errors, so perhaps it would be good for consistency to add the AVERROR here too. // 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 2/9] avformat/http: Use AVERROR_HTTP_TOO_MANY_REQUESTS
On Mon, 22 Apr 2024, Derek Buitenhuis wrote: Added in thep previous commit. Typo in the commit message // 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] avdevice/avfoundation: fix macOS/iOS/tvOS SDK conditional checks
On Wed, 17 Apr 2024, Marvin Scholz wrote: This fixes the checks to properly use runtime feature detection and check the SDK version (*_MAX_ALLOWED) instead of the targeted version for the relevant APIs. As these things are pretty hard to think straight about, it could be good with a more concrete example of what this achieves. I.e. if building with -mmacosx-version-min=10.13, we can still use the macOS 10.15 specific APIs, if they were available at build time, via the runtime check. The target is still checked (*_MIN_REQUIRED) to avoid using deprecated methods when targeting new enough versions. --- libavdevice/avfoundation.m | 164 ++--- 1 file changed, 116 insertions(+), 48 deletions(-) The diff is pretty hard to read as is, but when applied and viewed with "git show -w", it becomes clearer. The changes from TARGET_OS_IPHONE to TARGET_OS_IOS is pretty subtle, iirc TARGET_OS_IPHONE was any non-desktop platform (ios/tvos/watchos etc), while TARGET_OS_IOS specifically is iOS. The change looks right, but it might be good to spell this out as well. Specifically also, that TARGET_OS_IPHONE covers a whole class of OSes, while TARGET_OS_IOS is one OS - but the version defines for that OS are __IPHONE_OS_VERSION_MIN_REQUIRED and __IPHONE_OS_VERSION_MAX_ALLOWED. + /* If the targeted macOS is new enough, this fallback case can never be reached, so do not + * use a deprecated API to avoid compiler warnings. + */ This sentence gets somewhat warped up at some point, so I don't think it exactly means and is understandable as you meant it. What about this: If the targeted macOS is new enough, use of older APIs will cause deprecation warnings. Due to the availability check, we actually won't ever execute the code in such builds, but the compiler will still warn about it, unless we actually ifdef out the reference. Outside of what the patch does, I see the existing file uses this construct in a few places: #if !TARGET_OS_IPHONE && __MAC_OS_X_VERSION_MIN_REQUIRED >= 1070 I think it would seem more consistent to update this to use TARGET_OS_OSX instead of negating TARGET_OS_IPHONE - or is there something I'm missing? As for alternative ways of doing this, that would be less unwieldy - I have something like this in mind: #define SDK_AT_LEAST(macos, ios, tvos) \ (TARGET_OS_OSX&& MAC_OS_X_VERSION_MAX_ALLOWED>= macos) || \ (TARGET_OS_IOS&& __IPHONE_OS_VERSION_MAX_ALLOWED >= ios) || \ (TARGET_OS_TV && __TV_OS_VERSION_MAX_ALLOWED >= tvos) #if SDK_AT_LEAST(__MAC_10_15, __IPHONE_10_0, __TVOS_17_0) We could add similar macros for both SDK_AT_LEAST and TARGET_VERSION_AT_LEAST, and variants for different combinations of macos/ios/tvos for when we don't want to specify all of them. We can't use defined(macos) etc within this context though, so if we want to go this way, we'd need to start out with ifdefs for all the defines we use, like this: #ifndef __MAC_10_15 #define __MAC_10_15 #endif There's of course a bit of fragility here, we need to make sure that we actually copypaste the exact right value here. But on the other hand, we even could make it intentionally something else, e.g. like this: #ifndef __MAC_10_15 // If the SDK doesn't define this constant, the SDK doesn't support this version anyway, and we won't end up selecting it, so just use a dummy value instead. #define __MAC_10_15 #endif What do you think, does any of that seem like it would make the code more manageable? // 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".
[FFmpeg-devel] [PATCH v2] opusdsp: add ability to modify deemphasis constant
xHE-AAC relies on the same postfilter mechanism
that Opus uses to improve clarity (albeit with a steeper
deemphasis filter).
The code to apply it is identical, it's still just a
simple IIR low-pass filter. This commit makes it possible
to use alternative constants.
Version 2 changes:
Move the deemphasis constant table to opustab.c and
document its values better.
>From e6d0621f61bb39929548cab5fa047c1827e1ab8c Mon Sep 17 00:00:00 2001
From: Lynne
Date: Mon, 29 Jan 2024 04:31:43 +0100
Subject: [PATCH v2] opusdsp: add ability to modify deemphasis constant
xHE-AAC relies on the same postfilter mechanism
that Opus uses to improve clarity (albeit with a steeper
deemphasis filter).
The code to apply it is identical, it's still just a
simple IIR low-pass filter. This commit makes it possible
to use alternative constants.
---
libavcodec/aarch64/opusdsp_init.c | 2 +-
libavcodec/aarch64/opusdsp_neon.S | 28 +---
libavcodec/opusdec_celt.c | 6 --
libavcodec/opusdsp.c | 6 --
libavcodec/opusdsp.h | 4 +---
libavcodec/opustab.c | 28
libavcodec/opustab.h | 2 ++
libavcodec/x86/opusdsp.asm| 9 +++--
libavcodec/x86/opusdsp_init.c | 2 +-
9 files changed, 49 insertions(+), 38 deletions(-)
diff --git a/libavcodec/aarch64/opusdsp_init.c b/libavcodec/aarch64/opusdsp_init.c
index bb6d71b66b..a727006593 100644
--- a/libavcodec/aarch64/opusdsp_init.c
+++ b/libavcodec/aarch64/opusdsp_init.c
@@ -23,7 +23,7 @@
#include "libavcodec/opusdsp.h"
void ff_opus_postfilter_neon(float *data, int period, float *gains, int len);
-float ff_opus_deemphasis_neon(float *out, float *in, float coeff, int len);
+float ff_opus_deemphasis_neon(float *out, float *in, float coeff, const float *weights, int len);
av_cold void ff_opus_dsp_init_aarch64(OpusDSP *ctx)
{
diff --git a/libavcodec/aarch64/opusdsp_neon.S b/libavcodec/aarch64/opusdsp_neon.S
index e933151ab4..253825aa61 100644
--- a/libavcodec/aarch64/opusdsp_neon.S
+++ b/libavcodec/aarch64/opusdsp_neon.S
@@ -18,29 +18,11 @@
#include "libavutil/aarch64/asm.S"
- // 0.85..^10.85..^20.85..^30.85..^4
-const tab_st, align=4
-.word 0x3f599a00, 0x3f38f671, 0x3f1d382a, 0x3f05a32f
-endconst
-const tab_x0, align=4
-.word 0x0,0x3f599a00, 0x3f38f671, 0x3f1d382a
-endconst
-const tab_x1, align=4
-.word 0x0,0x0,0x3f599a00, 0x3f38f671
-endconst
-const tab_x2, align=4
-.word 0x0,0x0,0x0,0x3f599a00
-endconst
-
function ff_opus_deemphasis_neon, export=1
-movrel x4, tab_st
-ld1 {v4.4s}, [x4]
-movrel x4, tab_x0
-ld1 {v5.4s}, [x4]
-movrel x4, tab_x1
-ld1 {v6.4s}, [x4]
-movrel x4, tab_x2
-ld1 {v7.4s}, [x4]
+ld1 {v4.4s}, [x2], #16
+ld1 {v5.4s}, [x2], #16
+ld1 {v6.4s}, [x2], #16
+ld1 {v7.4s}, [x2]
fmulv0.4s, v4.4s, v0.s[0]
@@ -63,7 +45,7 @@ function ff_opus_deemphasis_neon, export=1
st1 {v1.4s, v2.4s}, [x0], #32
fmulv0.4s, v4.4s, v2.s[3]
-subsw2, w2, #8
+subsw3, w3, #8
b.gt1b
mov s0, v2.s[3]
diff --git a/libavcodec/opusdec_celt.c b/libavcodec/opusdec_celt.c
index fd8e9929e9..b19342337d 100644
--- a/libavcodec/opusdec_celt.c
+++ b/libavcodec/opusdec_celt.c
@@ -460,7 +460,9 @@ int ff_celt_decode_frame(CeltFrame *f, OpusRangeCoder *rc,
/* deemphasis */
block->emph_coeff = f->opusdsp.deemphasis(output[i],
>buf[1024 - frame_size],
- block->emph_coeff, frame_size);
+ block->emph_coeff,
+ ff_opus_deemph_weights,
+ frame_size);
}
if (channels == 1)
@@ -516,7 +518,7 @@ void ff_celt_flush(CeltFrame *f)
* a lesser discontinuity when seeking.
* The deemphasis functions differ from libopus in that they require
* an initial state divided by the coefficient. */
-block->emph_coeff = 0.0f / CELT_EMPH_COEFF;
+block->emph_coeff = 0.0f / ff_opus_deemph_weights[0];
}
f->seed = 0;
diff --git a/libavcodec/opusdsp.c b/libavcodec/opusdsp.c
index 0764d712e4..e61cc36098 100644
--- a/libavcodec/opusdsp.c
+++ b/libavcodec/opusdsp.c
@@ -18,6 +18,7 @@
#include "config.h"
#include "libavutil/attributes.h"
+#include "libavutil/mem_internal.h"
#include "opusdsp.h"
static void postfilter_c(float *data, int period, float *gains, int len)
@@ -43,10 +44,11 @@ static void
Re: [FFmpeg-devel] Fw: Your GSoC Org has 0 Contributors ranked - deadline is 1800 UTC April 24
On Wed, Apr 24, 2024 at 07:59:17AM +0200, Thilo Borgmann via ffmpeg-devel wrote: > Hi, > > > adding people who "want to mentor" to CC > > > > thx > > > > On Wed, Apr 24, 2024 at 01:50:31AM +0200, Michael Niedermayer wrote: > > > Hi all > > > > > > I just got the mail below. I assume the other admins are going to rank > > > them > > > before the deadline like they did last year. (but i can of course not > > > assume > > > that because there is no time if that doesnt happen) > > > I have not followed GSoC last year or this year much ... > > > > > > Either way, if you are a mentor and want your student to receive a slot > > > tell me privatly (with thilo and reynaldo in CC) ASAP how you would > > > rank your student. And i will rank him/her accordingly if i see noone > > > else starting to assign ranks > > sorry for delay, just got home after NAB. > All proposals now ranked, all admins/mentors should be able to see that on > the dashboard. confirmed, they look ranked thx! [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Whats the most studid thing your enemy could do ? Blow himself up Whats the most studid thing you could do ? Give up your rights and freedom because your enemy blew himself up. signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v3] lavu/opt: Clarify the scope of AVOptions
See discussion on the mailing list: https://ffmpeg.org/pipermail/ffmpeg-devel/2024-April/326054.html --- libavutil/opt.h | 10 ++ 1 file changed, 10 insertions(+) diff --git a/libavutil/opt.h b/libavutil/opt.h index e6013662f6..6cf2b39a63 100644 --- a/libavutil/opt.h +++ b/libavutil/opt.h @@ -53,6 +53,16 @@ * question is allowed to access the field. This allows us to extend the * semantics of those fields without breaking API compatibility. * + * @section avoptions_scope Scope of AVOptions + * + * AVOptions is designed to support any set of multimedia configuration options + * that can be defined at compile-time. Although it is mainly used to expose + * FFmpeg options, you are welcome to adapt it to your own use case. + * + * No single approach can ever fully solve the problem of configuration, + * but please submit a patch if you believe you have found a problem + * that is best solved by extending AVOptions. + * * @section avoptions_implement Implementing AVOptions * This section describes how to add AVOptions capabilities to a struct. * -- 2.43.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 3/5] doc/examples/vaapi_transcode: Simplify loop
On Wed, Apr 24, 2024 at 9:45 AM Michael Niedermayer wrote: > > Fixes: CID1428858(1/2) Logically dead code > > Sponsored-by: Sovereign Tech Fund > Signed-off-by: Michael Niedermayer > --- > doc/examples/vaapi_transcode.c | 4 +--- > 1 file changed, 1 insertion(+), 3 deletions(-) > > diff --git a/doc/examples/vaapi_transcode.c b/doc/examples/vaapi_transcode.c > index 8367cb30404..e1b7a438836 100644 > --- a/doc/examples/vaapi_transcode.c > +++ b/doc/examples/vaapi_transcode.c > @@ -215,10 +215,8 @@ static int dec_enc(AVPacket *pkt, const AVCodec > *enc_codec) > > fail: > av_frame_free(); > -if (ret < 0) > -return ret; > } > -return 0; > +return ret; > } > it's ok, thx > int main(int argc, char **argv) > -- > 2.43.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] Cease and desist
To whom it may concern. Stop your harassment and withdraw your public insults against my person. In light of prompt action from the Cc, I reserve any and all legal avenues against Thilo Borgmann. Le 24 avril 2024 09:07:43 GMT+03:00, Thilo Borgmann via ffmpeg-devel a écrit : >Hi, > >> Thilo is calling Kieran, myself and presumably Derek and JB trolls. >> >> This seems to be a pattern against anyone who disagrees with him. > >please avoid top-posting on this list [1]. > >-Thilo > >[1] https://ffmpeg.org/mailing-list-faq.html#What-is-top_002dposting_003f-1 > > >> Le 22 avril 2024 04:25:20 GMT+08:00, Thilo Borgmann via ffmpeg-devel >> a écrit : >>> Hi, >>> >>> On 21.04.24 10:47, Rémi Denis-Courmont wrote: Hi, I have been dragged privately into this issue so for the sake of transparency, I will just sum up my side here. Le 17 avril 2024 07:21:18 GMT+08:00, Devin Heitmueller a écrit : > Hello all, > > I wasn't looking to start trouble, but I didn't see any discussion of > this on the mailing list so wanted to bring it to the developer > community's attention. > > I attended the NAB conference and went by the "ffmpeg" booth on > Sunday. What I found was a single table with the official ffmpeg > banner hanging right next to a banner for the GPAC project, and two > salespeople from GPAC handing out marketing literature and trying to > educate me on why I should use their framework for my next project. Thilo did announce that some unidentified party would be payind for FFmpeg to hold a booth (this should be visible in the archives). Kieran raised legitimate if not concerning questions based on his prior experience at NAB. >>> I announced that "We reiceived an anonymous corporate sponsorship for the >>> booth, so there are no costs for the FFmpeg project to it (and no >>> obligations, of course)." >>> >>> Kieran's reaction was raising concerns that he feels donors wouldn't want >>> to see their SPI money spend on NAB [1][2] - ignoring that I'd just >>> announced that there will be no donor's SPI money needed as there are no >>> costs for FFmpeg. >>> >>> Kieran's reaction further was claiming that no plan has been provided who >>> will actually be present on the booth [1][2] - ignoring that I'd just >>> announced that "Any FFmpeg developer is welcome to join in and man the >>> booth with me". >>> >>> Thilo did not answer, which is inexcusable, especially considering that there were several times that the questions were reiterated. >>> Ignoring what has been said, making statements raising the impression that >>> something contradictory would be the truth is trolling me and deceiving the >>> other readers. No reason at all to feed the trolls - no matter how often >>> the trolling is repeated. >>> >>> Thilo privately called Kieran a "troll" as the lame pretext for not answering the question (I can copy the CC privately if proof of this is needed). >>> >>> And I just did publicly, for what I believe his reaction in the FFmpeg at >>> NAB 2024 thread was and everyone can read to get their own impression in >>> the archives. You think it's a lame pretext? The "questions" had been >>> answered even before they were "raised" by Kieran. >>> >>> In light of this, it seemed obvious that the FFmpeg booth would be a disaster, pretty much how Kieran had predicted. >>> >>> In the light of... the costs being covered and me + any other volunteer >>> manning the booth as announced or in the light of... the deceiving >>> 'ignorance' in Kieran's statements? >>> _Even if_ the coverage of the complete funding and/or manning the booth >>> would have been unanswered, how would that have 'obviusly' concluded the >>> booth to become a disaster? >>> That conclusion itself appears not comprehensible. >>> >>> So there you have it. On the bright side, FFmpeg was not footing the bill. >>> >>> I fear FFmpeg has to pay quite a high bill for all the trolling bullshit >>> going on about this NAB presence alone. >>> >>> I think everybody can make their own conclusions without me speculating or opiniating further, so I will leave it at that. >>> >>> I very much hope everyone is making up their own opinion. >>> Even you, who I think is not stupid, obviously was too easily made to >>> takeover the 'payment is unclear', 'manning is unclear', 'will become a >>> desaster' narrative here. >>> >>> > I'm not saying that GPAC shouldn't be able to have a table at the > conference, but it feels pretty misleading to have an "ffmpeg" booth > listed in the conference materials, with a table prominently > displaying the ffmpeg logo, with zero people from ffmpeg and people > pushing users to use an alternative framework that some might actually > considered to be a competitor to ffmpeg. Agreed. Thanks for your
Re: [FFmpeg-devel] FFmpeg table at NAB
Hi, Thilo is calling Kieran, myself and presumably Derek and JB trolls. This seems to be a pattern against anyone who disagrees with him. please avoid top-posting on this list [1]. -Thilo [1] https://ffmpeg.org/mailing-list-faq.html#What-is-top_002dposting_003f-1 Le 22 avril 2024 04:25:20 GMT+08:00, Thilo Borgmann via ffmpeg-devel a écrit : Hi, On 21.04.24 10:47, Rémi Denis-Courmont wrote: Hi, I have been dragged privately into this issue so for the sake of transparency, I will just sum up my side here. Le 17 avril 2024 07:21:18 GMT+08:00, Devin Heitmueller a écrit : Hello all, I wasn't looking to start trouble, but I didn't see any discussion of this on the mailing list so wanted to bring it to the developer community's attention. I attended the NAB conference and went by the "ffmpeg" booth on Sunday. What I found was a single table with the official ffmpeg banner hanging right next to a banner for the GPAC project, and two salespeople from GPAC handing out marketing literature and trying to educate me on why I should use their framework for my next project. Thilo did announce that some unidentified party would be payind for FFmpeg to hold a booth (this should be visible in the archives). Kieran raised legitimate if not concerning questions based on his prior experience at NAB. I announced that "We reiceived an anonymous corporate sponsorship for the booth, so there are no costs for the FFmpeg project to it (and no obligations, of course)." Kieran's reaction was raising concerns that he feels donors wouldn't want to see their SPI money spend on NAB [1][2] - ignoring that I'd just announced that there will be no donor's SPI money needed as there are no costs for FFmpeg. Kieran's reaction further was claiming that no plan has been provided who will actually be present on the booth [1][2] - ignoring that I'd just announced that "Any FFmpeg developer is welcome to join in and man the booth with me". Thilo did not answer, which is inexcusable, especially considering that there were several times that the questions were reiterated. Ignoring what has been said, making statements raising the impression that something contradictory would be the truth is trolling me and deceiving the other readers. No reason at all to feed the trolls - no matter how often the trolling is repeated. Thilo privately called Kieran a "troll" as the lame pretext for not answering the question (I can copy the CC privately if proof of this is needed). And I just did publicly, for what I believe his reaction in the FFmpeg at NAB 2024 thread was and everyone can read to get their own impression in the archives. You think it's a lame pretext? The "questions" had been answered even before they were "raised" by Kieran. In light of this, it seemed obvious that the FFmpeg booth would be a disaster, pretty much how Kieran had predicted. In the light of... the costs being covered and me + any other volunteer manning the booth as announced or in the light of... the deceiving 'ignorance' in Kieran's statements? _Even if_ the coverage of the complete funding and/or manning the booth would have been unanswered, how would that have 'obviusly' concluded the booth to become a disaster? That conclusion itself appears not comprehensible. So there you have it. On the bright side, FFmpeg was not footing the bill. I fear FFmpeg has to pay quite a high bill for all the trolling bullshit going on about this NAB presence alone. I think everybody can make their own conclusions without me speculating or opiniating further, so I will leave it at that. I very much hope everyone is making up their own opinion. Even you, who I think is not stupid, obviously was too easily made to takeover the 'payment is unclear', 'manning is unclear', 'will become a desaster' narrative here. I'm not saying that GPAC shouldn't be able to have a table at the conference, but it feels pretty misleading to have an "ffmpeg" booth listed in the conference materials, with a table prominently displaying the ffmpeg logo, with zero people from ffmpeg and people pushing users to use an alternative framework that some might actually considered to be a competitor to ffmpeg. Agreed. Thanks for your testimony. And here you are demonstrating again that it appears to be so much beloved behavior in our community to hop on the troll train and willingly ignore previous statement for the sake to troll on. You love to ignore what I relied to Devin's mail where to the most important part, Devin's impression could be reasonably explained/voided to have been a wrong impression (misleading ffmpeg booth without any people from ffmpeg) that to my understanding after talking to him, doesn't bother him anymore. You can think about GPAC what you want and if it is a good idea to share a booth with them. My thoughts about it is that we should absorb them into FFmpeg instead of splitting resources and efforts. They know that
