Re: [FFmpeg-devel] [PATCH v1] libavfi/dnn: add Paddle Inference as one of DNN backend
> On May 10, 2023, at 10:25, WenzheWang wrote: > > Dear Madam or Sir, > > > Hope this email finds you well. > > > I am writing this email since i recently found FFmepg remove DNN native > backend, and i will be really grateful if you let me know if there is any > new plan on libavfilter/dnn. > > > I would like to explain to you again about the addition of dnn paddle backend. > > At present, ffmpeg only supports openvino and tensorflow backend. Among the > current deep learning frameworks, TensorFlow is the most active in > development. TensorFlow has 174k stars and pytorch has 66.5k. openvino is > 4.2k, and the models that openvino can implement are relatively few. But in > terms of attention on GitHub, there's no doubt that TensorFlow and pytorch > are more promising. Currently, the paddle framework has reached 20.2k stars > on github, which is much more widely used and active than frameworks such as > mxnet and caffe. Stars don't matter much here. Just for reference, there is a thread before: https://patchwork.ffmpeg.org/project/ffmpeg/patch/20220523092918.9548-2-ting...@intel.com/ > > Tensoflow has a very rich ecosystem. The TensorFlow models library updates > very quickly and has existing examples of deep learning applications for > image classification, object detection, image generation text, and > generation of adversus-network models. The dnn libavfilter module is > undoubtedly very necessary for tensorflow backend to support. But the > complexity of the TensorFlow API and the complexity of the training are > almost prohibitive, making it a love-hate framework. > > PyTorch framework tends to be applied to academic fast implementation, and > its industrial application performance is not good. For example, Pytorch > framework makes a model to run on a server, Android phone or embedded > system, and its performance is poor compared with other deep learning > frameworks. > > > PaddlePadddle is an open source framework of Baidu, which is also used by > many people in China. It is very consistent with the usage habits of > developers, but the practicability of the API still needs to be further > strengthened. However, Paddle is the only deep learning framework I have > ever used, which does not configure any third-party libraries and can be > used directly by cloning make. Besides, Paddle occupies a small amount of > memory and is fast. It also serves a considerable number of projects inside > Baidu, which is very strong in industrial application. And PaddlePaddle > supports multiple machine and multiple card training. > > > Users' choice of different deep learning frameworks is a personal choice, > and the reason why most of us chose paddle is because of its better support > for embedded development and different hardware platforms and because the > community is very active and has proposed industrial improvements and > implementations for some advanced models. Especially for the GPU, it > supports cuda and opencl, which means we can optimize the model no matter > what kind of graphics card is used. In my opinion, more backend support can > better improve dnn libavfilter modules. > > If there are any new changes in dnn libavfilter module, I will be very > willing to adjust our implementation with the new planning and provide > continuous maintenance. > > > > > Best Regards, > Wenzhe Wang > > > > > > > WenzheWang > wong...@foxmail.com > > > > > > > > --Original-- > From: "WenzheWang" > Date:Tue, Apr 11, 2023 11:03 PM > To:"ffmpeg-devel" > Subject:Re: [FFmpeg-devel] [PATCH v1] libavfi/dnn: add Paddle Inference > as one of DNN backend > > > > > Could you please briefly introduce the reason why not adding any dnn > backend? > > > > > Do you have any plan for the maintenance and development of the dnn backend > in the future? From my understanding, the current backend of dnn has > tensoflow, openvino and native, but this cannot meet the needs of users. > > > > > Thus, I believe adding other dnn backends will be great for user experience, > user growth, and industrial applications. In particular, various dnn backend > can be adapted to different application environments, and there are some > emerging inference engines that are faster and stronger, such as Pytorch and > Paddle. In addition, from the practical point of view, it is not difficult > for a deep learning practitioner to learn and use this framework, but how to > choose a framework and apply it in practice, people pay more attention to the > effect (recall and precision), and easy deployment, that is, high reasoning > performance efficiency. The main reason why Paddle is relatively mainstream > and why I want to add paddle backend is that it has a very high efficiency > and performance. There
Re: [FFmpeg-devel] [PATCH v1] libavfi/dnn: add Paddle Inference as one of DNN backend
Dear Madam or Sir, Hope this email finds you well. I am writing this email since i recently found FFmepg remove DNN native backend, and i will be really grateful if you let me know if there is any new plan on libavfilter/dnn. I would like to explain to you again about the addition of dnn paddle backend. At present, ffmpeg only supports openvino and tensorflow backend. Among the current deep learning frameworks, TensorFlow is the most active in development. TensorFlow has 174k stars and pytorch has 66.5k. openvino is 4.2k, and the models that openvino can implement are relatively few. But in terms of attention on GitHub, there's no doubt that TensorFlow and pytorch are more promising. Currently, the paddle framework has reached 20.2k stars on github, which is much more widely used and active than frameworks such as mxnet and caffe. Tensoflow has a very rich ecosystem. The TensorFlow models library updates very quickly and has existing examples of deep learning applications for image classification, object detection, image generation text, and generation of adversus-network models. The dnn libavfilter module is undoubtedly very necessary for tensorflow backend to support. But the complexity of the TensorFlow API and the complexity of the training are almost prohibitive, making it a love-hate framework. PyTorch framework tends to be applied to academic fast implementation, and its industrial application performance is not good. For example, Pytorch framework makes a model to run on a server, Android phone or embedded system, and its performance is poor compared with other deep learning frameworks. PaddlePadddle is an open source framework of Baidu, which is also used by many people in China. It is very consistent with the usage habits of developers, but the practicability of the API still needs to be further strengthened. However, Paddle is the only deep learning framework I have ever used, which does not configure any third-party libraries and can be used directly by cloning make. Besides, Paddle occupies a small amount of memory and is fast. It also serves a considerable number of projects inside Baidu, which is very strong in industrial application. And PaddlePaddle supports multiple machine and multiple card training. Users' choice of different deep learning frameworks is a personal choice, and the reason why most of us chose paddle is because of its better support for embedded development and different hardware platforms and because the community is very active and has proposed industrial improvements and implementations for some advanced models. Especially for the GPU, it supports cuda and opencl, which means we can optimize the model no matter what kind of graphics card is used. In my opinion, more backend support can better improve dnn libavfilter modules. If there are any new changes in dnn libavfilter module, I will be very willing to adjust our implementation with the new planning and provide continuous maintenance. Best Regards, Wenzhe Wang WenzheWang wong...@foxmail.com --Original-- From: "WenzheWang" 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] [REFUND-REQUEST] Travel cost & more for CLT 2023
Hi, Am 15.03.2023 um 20:30 schrieb Thilo Borgmann: for our recent appearance at the Chemnitzer Linux Tage, I'd like to request reimbursements for my travel cost. I picked up Carl-Eugen in Berlin and we drove to Chemnitz together (~560 km in total). All hotel costs and further costs for merch and the webcam were preliminarily covered by others. So for me, it is just 61,40 EUR for Gas. Thanks, Thilo I would like to add my expenses to this list: 1. hotel: 318 2. merch: t-shirts, polo-shirts, sweatshirts 876,08 3. transport: gas 79,41 + 79,94 + 39,80 + 69,97 = 269,12 4. equipment: webcam 4K multi remote control 79,99 --- => total: 1543,19 Euro Details: 1. We booked the same hotel suite during the weekend (Thilo Borgmann, Carl Eugen Hoyos, Alexander Strasser & me) as we did in the past. 2. After the old merch. box was almost empty and no shirts were left, we ordered new ones. The amount was planned to be enough for the next couple of years. All remaining shirts are with Thilo since he plans to go to Linux Days 2023 in Prague, Czech Republic, in October this year - I won't attend. 3. I transported my equipment and the box with 50 merch. shirts. 4. After we discussed this step several years, this time we decided to finally buy a new one and use it for the demo setup. The camera is with Thilo - see point 2. Best regards, Thomas. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avfilter/setpts: add command support
On Sun, 7 May 2023 at 23:47, Stefano Sabatini wrote:
>
> On date Monday 2023-05-01 22:01:05 +0100, Oleg Afanasyev wrote:
> > I'm using setpts to generate timelapses with slowdowns in the middle.
> > Using setpts filter requires complicated expr to handle intervals. This
> > patch allows commands to change expr and also adds a constant that
> > provides time of last command applications to allow specifying gradual
> > changes using difference between time and cmd time.
> >
> > --
> > with best regards
> > Oleg Afanasyev
>
> > From a714a0957a57c1d392feca0ba675ba5ac7c875ee Mon Sep 17 00:00:00 2001
> > From: Oleg
> > Date: Sat, 29 Apr 2023 19:56:46 +0100
> > Subject: [PATCH] avfilter/setpts: add command support
> >
> > Add support for changing expr on the fly.
> >
> > Signed-off-by: Oleg
> > ---
> > doc/filters.texi | 7 +
> > libavfilter/setpts.c | 68 +---
> > 2 files changed, 58 insertions(+), 17 deletions(-)
> >
> > diff --git a/doc/filters.texi b/doc/filters.texi
> > index 50e1682144..fbdb1f8ecf 100644
> > diff --git a/libavfilter/setpts.c b/libavfilter/setpts.c
> > index 5bcc0c2dcf..7b09ce7707 100644
> > --- a/libavfilter/setpts.c
> > +++ b/libavfilter/setpts.c
> [...]
> > +static int process_command(AVFilterContext *ctx, const char *cmd, const
> > char *arg,
> > + char *res, int res_len, int flags)
> > +{
> > +SetPTSContext *setpts = ctx->priv;
> > +int ret;
> > +
> > +ret = ff_filter_process_command(ctx, cmd, arg, res, res_len, flags);
> > +
> > +if (ret < 0)
> > +return ret;
> > +
>
> > +if (!strcmp(cmd, "expr")) {
> > +av_expr_free(setpts->expr);
> > +ret = av_expr_parse(>expr, arg, var_names, NULL, NULL,
> > NULL, NULL, 0, ctx);
> > +if (ret < 0) {
> > +av_log(ctx, AV_LOG_ERROR, "Error while parsing expression
> > '%s'\n", arg);
> > +}
>
> what happens in case setpts->expr is freed and this fails?
>
> probably it should keep a reference to expr and remove it only in case
> the new expression was successfully parsed
Fixed! Didn't realize that encoding continues even if command fails,
so it was crashing with the previous expression still in place.
>
> [...]
>
> Looks good to me otherwise.
>
> ___
> 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".
From a50bf9e58a0f90d63aba3c84de40f31dc22ebfce Mon Sep 17 00:00:00 2001
From: Oleg
Date: Sat, 29 Apr 2023 19:56:46 +0100
Subject: [PATCH] avfilter/setpts: add command support
Add support for changing expr on the fly.
Signed-off-by: Oleg
---
doc/filters.texi | 7 +
libavfilter/setpts.c | 73 +---
2 files changed, 63 insertions(+), 17 deletions(-)
diff --git a/doc/filters.texi b/doc/filters.texi
index 50e1682144..fbdb1f8ecf 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -29384,6 +29384,9 @@ The wallclock (RTC) time at the start of the movie in microseconds.
@item TB
The timebase of the input timestamps.
+@item T_CHANGE
+Time of the first frame after command was applied or time of the first frame if no commands.
+
@end table
@subsection Examples
@@ -29439,6 +29442,10 @@ asetpts=N/SR/TB
@end itemize
+@subsection Commands
+
+Both filters support all above options as @ref{commands}.
+
@section setrange
Force color range for the output video frame.
diff --git a/libavfilter/setpts.c b/libavfilter/setpts.c
index 5bcc0c2dcf..c805a60ee4 100644
--- a/libavfilter/setpts.c
+++ b/libavfilter/setpts.c
@@ -63,6 +63,7 @@ static const char *const var_names[] = {
"S", // Number of samples in the current frame
"SR", // Audio sample rate
"FR", ///< defined only for constant frame-rate video
+"T_CHANGE",///< time of first frame after latest command was applied
NULL
};
@@ -90,7 +91,8 @@ enum var_name {
VAR_S,
VAR_SR,
VAR_FR,
-VAR_VARS_NB
+VAR_T_CHANGE,
+VAR_VARS_NB,
};
typedef struct SetPTSContext {
@@ -120,6 +122,7 @@ static av_cold int init(AVFilterContext *ctx)
setpts->var_values[VAR_PREV_OUTT] = NAN;
setpts->var_values[VAR_STARTPTS]= NAN;
setpts->var_values[VAR_STARTT] = NAN;
+setpts->var_values[VAR_T_CHANGE]= NAN;
return 0;
}
@@ -163,6 +166,9 @@ static double eval_pts(SetPTSContext *setpts, AVFilterLink *inlink, AVFrame *fra
setpts->var_values[VAR_STARTPTS] = TS2D(pts);
setpts->var_values[VAR_STARTT ] = TS2T(pts, inlink->time_base);
}
+if (isnan(setpts->var_values[VAR_T_CHANGE])) {
+setpts->var_values[VAR_T_CHANGE] = TS2T(pts, inlink->time_base);
+}
setpts->var_values[VAR_PTS ] = TS2D(pts);
setpts->var_values[VAR_T ] =
Re: [FFmpeg-devel] [PATCH 1/3] avformat/dashdec: fail on probing non mpd file extension
On Tue, May 09, 2023 at 08:19:36AM +0200, Anton Khirnov wrote:
> Quoting Michael Niedermayer (2023-05-09 00:35:08)
> > On Mon, May 08, 2023 at 04:05:40PM +0200, Tobias Rapp wrote:
> > > On 08/05/2023 14:00, James Almer wrote:
> > >
> > > > On 5/6/2023 10:25 AM, Michael Niedermayer wrote:
> > > > > Its unexpected that a .avi or other "standard" file turns into a
> > > > > playlist.
> > > > > The goal of this patch is to avoid this unexpected behavior and
> > > > > possible
> > > > > privacy or security differences.
> > > > >
> > > > > This is similar to the same change to hls
> > > > >
> > > > > Signed-off-by: Michael Niedermayer
> > > > > ---
> > > > > libavformat/dashdec.c | 11 +++
> > > > > 1 file changed, 7 insertions(+), 4 deletions(-)
> > > > >
> > > > > diff --git a/libavformat/dashdec.c b/libavformat/dashdec.c
> > > > > index 29d4680c68..294e14150d 100644
> > > > > --- a/libavformat/dashdec.c
> > > > > +++ b/libavformat/dashdec.c
> > > > > @@ -2336,10 +2336,13 @@ static int dash_probe(const AVProbeData *p)
> > > > > av_stristr(p->buf, "dash:profile:isoff-live:2011") ||
> > > > > av_stristr(p->buf, "dash:profile:isoff-live:2012") ||
> > > > > av_stristr(p->buf, "dash:profile:isoff-main:2011") ||
> > > > > - av_stristr(p->buf, "3GPP:PSS:profile:DASH1")) {
> > > > > - return AVPROBE_SCORE_MAX;
> > > > > - }
> > > > > - if (av_stristr(p->buf, "dash:profile")) {
> > > > > + av_stristr(p->buf, "3GPP:PSS:profile:DASH1") ||
> > > > > + av_stristr(p->buf, "dash:profile")) {
> > > > > + if (!av_match_ext(p->filename, "mpd")) {
> > > > > + av_log(NULL, AV_LOG_ERROR, "Not detecting dash with non
> > > > > standard extension\n");
> > > > > + return 0;
> > > > > + }
> > > > > +
> > > > > return AVPROBE_SCORE_MAX;
> > > > > }
> > > >
> > > > Failing because it didn't match an extensions sort of goes against the
> > > > point of probing, which even has a low score return value that's
> > > > basically "it matched extension" as a sort of last resort.
> > > >
> > > > I'd say wrap this in a FF_COMPLIANCE_STRICT check (since i assume the
> > > > spec does state mpd must be the extension), but i think we have no
> > > > access to the AVFormatContext here?
> > >
> > > DASH is usually transferred over HTTP where file extensions are of minor
> > > interest, the relevant type information is in the Mime-Type header.
> >
> > would anyone be opposed to return 0 from dash_probe() when
> > both the mime_type and the extension are wrong ?
>
> I would.
>
> probe() is for probing, not implementing security policies. IMO trying
> to fix security issues at the wrong layer will only lead to more
> confusion, more complexity, and LESS security.
YES i agree, probe is not for security policies
Its for probing but IMHO
If you have a
taxreport.pdf that parses correctly as jar and installs jRAT if you execute it
Then it would be valid for probe() to identify this as type exploit instead
of type jar. And doing so would be more secure.
This is really more along the line of thought here for hls too.
a file with avi/mkv/mov/mxf/mpg/mp4 extension is not a hls playlist
Could someone have added that extension by mistake, yes
similarly your jar file could be named .pdf by mistake. But thats not
a good default assumtation and i dont think anyone would assume that
by default.
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
If the United States is serious about tackling the national security threats
related to an insecure 5G network, it needs to rethink the extent to which it
values corporate profits and government espionage over security.-Bruce Schneier
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/3] avformat/dashdec: fail on probing non mpd file extension
On Tue, May 09, 2023 at 09:35:09AM +0200, Tobias Rapp wrote: > On 09/05/2023 08:19, Anton Khirnov wrote: > > > Quoting Michael Niedermayer (2023-05-09 00:35:08) > > > On Mon, May 08, 2023 at 04:05:40PM +0200, Tobias Rapp wrote: > > > > [...] > > > > DASH is usually transferred over HTTP where file extensions are of minor > > > > interest, the relevant type information is in the Mime-Type header. > > > would anyone be opposed to return 0 from dash_probe() when > > > both the mime_type and the extension are wrong ? > > I would. > > > > probe() is for probing, not implementing security policies. IMO trying > > to fix security issues at the wrong layer will only lead to more > > confusion, more complexity, and LESS security. > > I agree that probing should be unrelated to the actual format selection > policy. > > > > example: a crafted image.jpeg uploaded somewhere is played as dash. > > > or am i missing something that would stop that ? > The player application could exclude the dash format (and other playlist > formats) from the format_whitelist I guess? That would push the problem down to every application which is really not a very good solution Its even worse because every player than needs to also know which format is a playlist format. Including all future ones and then also if the user minds them being disabled completely thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB "You are 36 times more likely to die in a bathtub than at the hands of a terrorist. Also, you are 2.5 times more likely to become a president and 2 times more likely to become an astronaut, than to die in a terrorist attack." -- Thoughty2 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 11/13] lavc/libvpxenc: send frame durations to the encoder
On Tue, May 9, 2023 at 2:10 AM Anton Khirnov wrote:
>
> Adapt similar code from libaomenc - stop using ticks_per_frame except as
> a last resort.
> ---
> libavcodec/libvpxenc.c | 15 +--
> 1 file changed, 13 insertions(+), 2 deletions(-)
>
lgtm.
> diff --git a/libavcodec/libvpxenc.c b/libavcodec/libvpxenc.c
> index a20e949842..f70cc87c41 100644
> --- a/libavcodec/libvpxenc.c
> +++ b/libavcodec/libvpxenc.c
> @@ -1692,6 +1692,7 @@ static int vpx_encode(AVCodecContext *avctx, AVPacket
> *pkt,
> const struct vpx_codec_enc_cfg *enccfg = ctx->encoder.config.enc;
> vpx_svc_layer_id_t layer_id;
> int layer_id_valid = 0;
> +unsigned long duration = 0;
>
> if (avctx->qmax >= 0 && enccfg->rc_max_quantizer != avctx->qmax) {
> struct vpx_codec_enc_cfg cfg = *enccfg;
> @@ -1820,8 +1821,18 @@ static int vpx_encode(AVCodecContext *avctx, AVPacket
> *pkt,
> #endif
> }
>
> +if (frame && frame->duration > ULONG_MAX) {
> +av_log(avctx, AV_LOG_WARNING,
> + "Frame duration too large: %"PRId64"\n", frame->duration);
This could fall back to frame rate or ticks, but I imagine this case
would be unlikely in practice unless the timebase was quite large.
> +} else if (frame && frame->duration)
> +duration = frame->duration;
> +else if (avctx->framerate.num > 0 && avctx->framerate.den > 0)
> +duration = av_rescale_q(1, av_inv_q(avctx->framerate),
> avctx->time_base);
> +else
> +duration = avctx->ticks_per_frame ? avctx->ticks_per_frame : 1;
> +
> res = vpx_codec_encode(>encoder, rawimg, timestamp,
> - avctx->ticks_per_frame, flags, ctx->deadline);
> + duration, flags, ctx->deadline);
> if (res != VPX_CODEC_OK) {
> log_encoder_error(avctx, "Error encoding frame");
> return AVERROR_INVALIDDATA;
> @@ -1829,7 +1840,7 @@ static int vpx_encode(AVCodecContext *avctx, AVPacket
> *pkt,
>
> if (ctx->is_alpha) {
> res = vpx_codec_encode(>encoder_alpha, rawimg_alpha, timestamp,
> - avctx->ticks_per_frame, flags, ctx->deadline);
> + duration, flags, ctx->deadline);
> if (res != VPX_CODEC_OK) {
> log_encoder_error(avctx, "Error encoding alpha frame");
> return AVERROR_INVALIDDATA;
> --
> 2.39.2
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] web/download: link to the latest release instead of a snapshot in the main download button
As suggested on IRC. There's already an Snapshot section right below it, and the links to the actual releases are much lower and harder to find. Also, remove the massive signing key button and move it to the snapshot section. There's already "Release Verification" section below with a detailed explanation and yet another link to the key. Signed-off-by: James Almer --- src/download | 13 ++--- 1 file changed, 6 insertions(+), 7 deletions(-) diff --git a/src/download b/src/download index beae4a9..285fdf7 100644 --- a/src/download +++ b/src/download @@ -1,15 +1,10 @@ -https://ffmpeg.org/releases/ffmpeg-snapshot.tar.bz2; class="btn btn-success"> +https://ffmpeg.org/releases/ffmpeg-6.0.tar.xz; class="btn btn-success"> Download Source Code - ffmpeg-snapshot.tar.bz2 - - - - Download PGP Signing Key - ffmpeg-devel.asc + ffmpeg-6.0.tar.xz More releases @@ -121,6 +116,10 @@ Download Snapshot + + + +Download PGP Signing Key -- 2.40.1 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 0/5] RISC-V: Improve H264 decoding performance using RVV intrinsic
Hi, Le tiistaina 9. toukokuuta 2023, 12.50.25 EEST Arnie Chang a écrit : > We are submitting a set of patches that significantly improve H.264 decoding > performance by utilizing RVV intrinsic code. I believe that there is a general dislike of compiler intrinsic for vector optimisations in FFmpeg for a plurality of reasons. FWIW, that dislike is not limited to FFmpeg: https://www.reddit.com/r/RISCV/comments/131hlgq/comment/ji1ie3l/ Indeed, in my personal opinion, RISC-V V intrinsics specifically are painful to read/write compared to assembler. On top of that, in this particular case, intrinsics have at least three, possibly four, additional and more objective challenges as compared to the existing RVV assembler: 1) They are less portable, requiring the most bleeding edge version of compilers. Case in point: our FATE GCC instance does not support them as of today (because Debian Unstable does not). 2) They do not work with run-time CPU detection, at least not currently. This is going to be a major stumbling point for Linux distributions which need to build code that runs on processors without vector unit. 3) V intrinsics require specifying the group multiplier at every instruction. In most cases, this is just very inconvenient. But in those algorithms that require a fixed vector size (e.g. Opus DSP already now), this simply does _not_ work. Essentially, this is the downside of relying on the compiler to do the register allocation. 4) (Unsure) Intrinsics are notorious for missing some code points. The first two points may be addressed eventually. But the third point is intrinsic to intrinsics (hohoho). So unless there is a case for why intrinsics would be all but _required_, please avoid them. Now I do realise that that means some of the code won't be XLEN-indepent. Well, we can cross that bridge with macros if/when somebody actually cares about FFmpeg vector optimisations on RV32I. Br, -- 雷米‧德尼-库尔蒙 http://www.remlab.net/ ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 0/5] RISC-V: Improve H264 decoding performance using RVV intrinsic
May 9, 2023, 11:51 by arnie.ch...@sifive.com: > We are submitting a set of patches that significantly improve H.264 decoding > performance > by utilizing RVV intrinsic code. The average speedup(FPS) achieved by these > patches is more than 2x, > as experimented on 720P videos running on an internal FPGA board. > > Patch1: add support for RVV intrinsic code in the configure file > Patch2: optimize chroma motion compensation > Patch3: optimize luma motion compensation > Patch4: optimize dsp functions, such as IDCT, in-loop filtering, and weighed > filtering > Patch5: optimize intra prediction > > Arnie Chang (5): > configure: Add detection of RISC-V vector intrinsic support > lavc/h264chroma: Add vectorized implementation of chroma MC for RISC-V > lavc/h264qpel: Add vectorized implementation of luma MC for RISC-V > lavc/h264dsp: Add vectorized implementation of DSP functions for > RISC-V > lavc/h264pred: Add vectorized implementation of intra prediction for > RISC-V > Could you rewrite this in asm instead? I'd like for risc-v to have the same policy like we do for arm - no intrinsics. There's a long list of reasons we don't use intrinsics which I won't get into. Just a few days ago, I discovered that our PPC intrinsics were quite badly performing due to compiler issues, in some cases, 500x slower than C. Also, we don't care about overall speedup. We have checkasm --bench to measure the per-function speedup over C. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] Status of Patches
On 2023-05-09 09:09 pm, Davy Durham wrote: Hi group, How does one check on the status of a submitted patch? I see many patches a day go into this list, but I have no idea if/when they have been incorporated. See https://patchwork.ffmpeg.org/project/ffmpeg/list/ 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] avformat/hls: fail on probing non hls/m3u8 file extensions
On Tue, May 09, 2023 at 08:15:34AM +0200, Anton Khirnov wrote: > Quoting Michael Niedermayer (2023-05-09 01:25:00) > > On Sun, May 07, 2023 at 10:42:56PM +0200, Anton Khirnov wrote: > > > Quoting Michael Niedermayer (2023-05-03 14:30:38) > > > > Its unexpected that a .avi or other "standard" file turns into a > > > > playlist. > > > > The goal of this patch is to avoid this unexpected behavior and possible > > > > privacy or security differences. > > > > > > > > > > I very much dislike this approach. > > > > What else do you suggest ? > > > > We could have a configuration option that specifies one > > or more trusted directories/files/urls. And everything outside would be > > limited to selfcontained files > > The average user can put * as trusted url if thats what they want > > While someone who cares about their privacy and security could restrict > > that with little effort to the place where they store their music and > > videos which they know is ok. While OTOH still throwing random URLs > > at ffmpeg without expecting overly unexpected results (not considering bugs) > > Thats similar to how some office software can handle macros. > > > > Or do you have some other suggestion ? > > > > I don't see what actual problem is this supposed to address. The commit > message mentions some vague "possible issues", but > * this seems like the wrong layer for this kind of policy decisions > * I think there needs to be a clearly defined thread model before we can > discuss what the right solution is Its not one threat but many. And i already mentioned some but we can pick one hypothetical example for sake of discussion and detail it more. (being more detailed this is sadly a longer mail) Lets assume an attacker wants to infiltrate a specific company part of that will require gaining access to the companies internal network. So the attacker starts chating with some employee, the medium of communication is irrelevant here. The attacker cannot just ask the employee to run his network scanner the employee would realize whats going on and report it (or should at least) Maybe the attacker asks the emplyee to look at that really funny weblog of his, but the emplyee might be trained not to open random links in his webbrowser or the webbrowser might be so locked down that it cant access the companies internal net. So our attacker sends him a link to companyX_boss_and_secretary_sex_hd.avi So he tries watching that because he now isnt sure if the guy meant that was about his boss or someone else, after all he knows its safe because he watched so much porn on so many shady sites with his video player and never got hacked from it. in reality that avi file is not a avi, its maybe some playlist allowing arbitrary URLs. While the employee watches some boss and secretary the bits any pieces betweem the scenes scan the companies internal network and the external http accesses which go back to the attacker, allow him to get all the information of it. The problem is that playing some files allows things like scaning the network and passing this information on to an attacker. I dont have a real full testcase so maybe theres something iam missing why this wouldnt work ... compounding that our probing code is really good and detects such attacks and makes them work even if the file is named incorrectly and has the wrong mime type. This makes such an attack easier to do and harder to detect even for a smart user ideal would be if the whole attack wouldnt work at all and network realms would be clearly seperated and nothing touching the companies private net or localnet could touch the public internet. This is not compatible with a playlist randomly mixing local, priavte and public content. If its just my own machiene, i have no such playlist and see no use in one for me. But some people want that i think. They maybe arent the employee who as part of his job has to protect the company and not play random playlists. Also they maybe arent the privacy or security concious users. Having default same origin policy and a list of files/directories/urls that are excempt from it would fix this in the example above. The companies employees would not override default security settings to watch a odd file. Or they could loose their job A user caring about security / privacy could setup the settings carefully so safe playlists work and other things are secure and A user not caring could just disable a same origin check, and this may be ok for her thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The real ebay dictionary, page 1 "Used only once"- "Some unspecified defect prevented a second use" "In good condition" - "Can be repaird by experienced expert" "As is" - "You wouldnt want it even if you were payed for it, if you knew ..." signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org
[FFmpeg-devel] Status of Patches
Hi group, How does one check on the status of a submitted patch? I see many patches a day go into this list, but I have no idea if/when they have been incorporated. Thanks ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] MXF - Add jpeg2000 subdescriptor - Sponsored by INA
Couple of follow-up comments.
- "mxf_parse_jpeg2000_frame" could be moved to one of jpeg2000 source
files, to keep J2K parsing code together. Maybe there is a way to
reuse jpeg2000_read_main_headers() at jpeg2000dec.c?
- when defining the J2K descriptor items, please refer to the symbol
name from the SMPTE registers, it make following/debugging the code a
lot easier:
{ 0x8405,
{0x06,0x0e,0x2b,0x34,0x01,0x01,0x01,0x0a,0x04,0x01,0x06,0x03,0x05,0x00,0x00,0x00}},
/* Vertical offset from the origin of the reference grid to the left
side of the image area */
becomes
{ 0x8405,
{0x06,0x0e,0x2b,0x34,0x01,0x01,0x01,0x0a,0x04,0x01,0x06,0x03,0x05,0x00,0x00,0x00}},
/* YOsiz: vertical offset from the origin of the reference grid to the
left side of the image area */
___
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 2/3] lavc: deprecate AV_CODEC_CAP_SUBFRAMES
There is nothing meaningful the caller can do with it.
---
doc/APIchanges | 3 +++
libavcodec/alsdec.c | 6 +-
libavcodec/apac.c | 6 --
libavcodec/apedec.c | 6 +-
libavcodec/atrac3.c | 12 ++--
libavcodec/atrac9dec.c | 6 +-
libavcodec/bonk.c | 6 --
libavcodec/codec.h | 3 +++
libavcodec/ftr.c| 6 +-
libavcodec/g723_1dec.c | 6 +-
libavcodec/g729dec.c| 12 ++--
libavcodec/libspeexdec.c| 6 +-
libavcodec/misc4.c | 5 -
libavcodec/shorten.c| 6 --
libavcodec/tests/avcodec.c | 3 +--
libavcodec/version_major.h | 1 +
libavcodec/wavarc.c | 2 ++
libavcodec/wmalosslessdec.c | 6 +-
libavcodec/wmaprodec.c | 18 +++---
libavcodec/wmavoice.c | 6 +-
20 files changed, 101 insertions(+), 24 deletions(-)
diff --git a/doc/APIchanges b/doc/APIchanges
index 20ab4709e7..a37fe1bb8e 100644
--- a/doc/APIchanges
+++ b/doc/APIchanges
@@ -2,6 +2,9 @@ The last version increases of all libraries were on 2023-02-09
API changes, most recent first:
+2023-05-xx - xx - lavc 60 - codec.h
+ Depreate AV_CODEC_CAP_SUBFRAMES without replacement.
+
2023-05-xx - xx - lavc 60.11.100 - codec_par.h
Add AVCodecParameters.framerate.
diff --git a/libavcodec/alsdec.c b/libavcodec/alsdec.c
index 4605b2248f..c64d1032a4 100644
--- a/libavcodec/alsdec.c
+++ b/libavcodec/alsdec.c
@@ -2190,6 +2190,10 @@ const FFCodec ff_als_decoder = {
.close = decode_end,
FF_CODEC_DECODE_CB(decode_frame),
.flush = flush,
-.p.capabilities = AV_CODEC_CAP_SUBFRAMES | AV_CODEC_CAP_DR1 |
AV_CODEC_CAP_CHANNEL_CONF,
+.p.capabilities =
+#if FF_API_SUBFRAMES
+ AV_CODEC_CAP_SUBFRAMES |
+#endif
+ AV_CODEC_CAP_DR1 | AV_CODEC_CAP_CHANNEL_CONF,
.caps_internal = FF_CODEC_CAP_INIT_CLEANUP,
};
diff --git a/libavcodec/apac.c b/libavcodec/apac.c
index 3408f75292..b6cb6c669e 100644
--- a/libavcodec/apac.c
+++ b/libavcodec/apac.c
@@ -269,8 +269,10 @@ const FFCodec ff_apac_decoder = {
FF_CODEC_DECODE_CB(apac_decode),
.close= apac_close,
.p.capabilities = AV_CODEC_CAP_DELAY |
-AV_CODEC_CAP_DR1 |
-AV_CODEC_CAP_SUBFRAMES,
+#if FF_API_SUBFRAMES
+AV_CODEC_CAP_SUBFRAMES |
+#endif
+AV_CODEC_CAP_DR1,
.caps_internal= FF_CODEC_CAP_INIT_CLEANUP,
.p.sample_fmts= (const enum AVSampleFormat[]) { AV_SAMPLE_FMT_U8P,
AV_SAMPLE_FMT_S16P,
diff --git a/libavcodec/apedec.c b/libavcodec/apedec.c
index 772636afde..613c76df0b 100644
--- a/libavcodec/apedec.c
+++ b/libavcodec/apedec.c
@@ -1680,7 +1680,11 @@ const FFCodec ff_ape_decoder = {
.init = ape_decode_init,
.close = ape_decode_close,
FF_CODEC_DECODE_CB(ape_decode_frame),
-.p.capabilities = AV_CODEC_CAP_SUBFRAMES | AV_CODEC_CAP_DELAY |
+.p.capabilities =
+#if FF_API_SUBFRAMES
+ AV_CODEC_CAP_SUBFRAMES |
+#endif
+ AV_CODEC_CAP_DELAY |
AV_CODEC_CAP_DR1,
.caps_internal = FF_CODEC_CAP_INIT_CLEANUP,
.flush = ape_flush,
diff --git a/libavcodec/atrac3.c b/libavcodec/atrac3.c
index 7415da590b..5851ee027c 100644
--- a/libavcodec/atrac3.c
+++ b/libavcodec/atrac3.c
@@ -1026,7 +1026,11 @@ const FFCodec ff_atrac3_decoder = {
.init = atrac3_decode_init,
.close= atrac3_decode_close,
FF_CODEC_DECODE_CB(atrac3_decode_frame),
-.p.capabilities = AV_CODEC_CAP_SUBFRAMES | AV_CODEC_CAP_DR1,
+.p.capabilities =
+#if FF_API_SUBFRAMES
+AV_CODEC_CAP_SUBFRAMES |
+#endif
+AV_CODEC_CAP_DR1,
.p.sample_fmts= (const enum AVSampleFormat[]) { AV_SAMPLE_FMT_FLTP,
AV_SAMPLE_FMT_NONE },
.caps_internal= FF_CODEC_CAP_INIT_CLEANUP,
@@ -1041,7 +1045,11 @@ const FFCodec ff_atrac3al_decoder = {
.init = atrac3_decode_init,
.close= atrac3_decode_close,
FF_CODEC_DECODE_CB(atrac3al_decode_frame),
-.p.capabilities = AV_CODEC_CAP_SUBFRAMES | AV_CODEC_CAP_DR1,
+.p.capabilities =
+#if FF_API_SUBFRAMES
+AV_CODEC_CAP_SUBFRAMES |
+#endif
+AV_CODEC_CAP_DR1,
.p.sample_fmts= (const enum AVSampleFormat[]) { AV_SAMPLE_FMT_FLTP,
AV_SAMPLE_FMT_NONE },
.caps_internal= FF_CODEC_CAP_INIT_CLEANUP,
diff --git a/libavcodec/atrac9dec.c b/libavcodec/atrac9dec.c
index 60962b1676..8a6940455d 100644
--- a/libavcodec/atrac9dec.c
+++ b/libavcodec/atrac9dec.c
@@ -1003,5 +1003,9 @@ const FFCodec ff_atrac9_decoder = {
Re: [FFmpeg-devel] [PATCH 2/3] lavc: deprecate AV_CODEC_CAP_SUBFRAMES
On 5/9/2023 9:02 AM, Anton Khirnov wrote: Quoting James Almer (2023-05-09 13:56:22) On 5/9/2023 7:30 AM, Anton Khirnov wrote: There is nothing meaningful the caller can do with it. --- libavcodec/alsdec.c | 6 +- libavcodec/apac.c | 6 -- libavcodec/apedec.c | 6 +- libavcodec/atrac3.c | 12 ++-- libavcodec/atrac9dec.c | 6 +- libavcodec/bonk.c | 6 -- libavcodec/codec.h | 3 +++ libavcodec/ftr.c| 6 +- libavcodec/g723_1dec.c | 6 +- libavcodec/g729dec.c| 12 ++-- libavcodec/libspeexdec.c| 6 +- libavcodec/misc4.c | 5 - libavcodec/shorten.c| 6 -- libavcodec/tests/avcodec.c | 3 +-- libavcodec/version_major.h | 1 + libavcodec/wavarc.c | 2 ++ libavcodec/wmalosslessdec.c | 6 +- libavcodec/wmaprodec.c | 18 +++--- libavcodec/wmavoice.c | 6 +- 19 files changed, 98 insertions(+), 24 deletions(-) Missing APIChanges entry. For that matter, when there's no replacement for a deprecated API, and thus there's no point in bumping minor, what should the APIChanges entry point to? Is there a point in having an APIchanges entry when no API actually changed? You have added entries saying "Deprecated X without replacement" before. ___ 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/3] lavc: deprecate AV_CODEC_CAP_SUBFRAMES
Quoting James Almer (2023-05-09 13:56:22) > On 5/9/2023 7:30 AM, Anton Khirnov wrote: > > There is nothing meaningful the caller can do with it. > > --- > > libavcodec/alsdec.c | 6 +- > > libavcodec/apac.c | 6 -- > > libavcodec/apedec.c | 6 +- > > libavcodec/atrac3.c | 12 ++-- > > libavcodec/atrac9dec.c | 6 +- > > libavcodec/bonk.c | 6 -- > > libavcodec/codec.h | 3 +++ > > libavcodec/ftr.c| 6 +- > > libavcodec/g723_1dec.c | 6 +- > > libavcodec/g729dec.c| 12 ++-- > > libavcodec/libspeexdec.c| 6 +- > > libavcodec/misc4.c | 5 - > > libavcodec/shorten.c| 6 -- > > libavcodec/tests/avcodec.c | 3 +-- > > libavcodec/version_major.h | 1 + > > libavcodec/wavarc.c | 2 ++ > > libavcodec/wmalosslessdec.c | 6 +- > > libavcodec/wmaprodec.c | 18 +++--- > > libavcodec/wmavoice.c | 6 +- > > 19 files changed, 98 insertions(+), 24 deletions(-) > > Missing APIChanges entry. > > For that matter, when there's no replacement for a deprecated API, and > thus there's no point in bumping minor, what should the APIChanges entry > point to? Is there a point in having an APIchanges entry when no API actually changed? -- Anton Khirnov ___ 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/3] lavc: deprecate AV_CODEC_CAP_SUBFRAMES
On 5/9/2023 7:30 AM, Anton Khirnov wrote: There is nothing meaningful the caller can do with it. --- libavcodec/alsdec.c | 6 +- libavcodec/apac.c | 6 -- libavcodec/apedec.c | 6 +- libavcodec/atrac3.c | 12 ++-- libavcodec/atrac9dec.c | 6 +- libavcodec/bonk.c | 6 -- libavcodec/codec.h | 3 +++ libavcodec/ftr.c| 6 +- libavcodec/g723_1dec.c | 6 +- libavcodec/g729dec.c| 12 ++-- libavcodec/libspeexdec.c| 6 +- libavcodec/misc4.c | 5 - libavcodec/shorten.c| 6 -- libavcodec/tests/avcodec.c | 3 +-- libavcodec/version_major.h | 1 + libavcodec/wavarc.c | 2 ++ libavcodec/wmalosslessdec.c | 6 +- libavcodec/wmaprodec.c | 18 +++--- libavcodec/wmavoice.c | 6 +- 19 files changed, 98 insertions(+), 24 deletions(-) Missing APIChanges entry. For that matter, when there's no replacement for a deprecated API, and thus there's no point in bumping minor, what should the APIChanges entry point to? ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] Add functions to identify devices in more ways
applied ___ 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/3] lavc/decode: drop a useless warning
Finally! ___ 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 v8 3/6] avformat/flvenc: support mux av1 in enhanced flv
On 2023-05-09 04:05 pm, Neal Gompa wrote:
On Tue, May 9, 2023 at 12:14 AM Gyan Doshi wrote:
On 2023-05-09 08:11 am, Neal Gompa wrote:
On Mon, May 8, 2023 at 9:55 PM Steven Liu wrote:
Neal Gompa 于2023年5月9日周二 07:08写道：
On Thu, Apr 13, 2023 at 5:45 AM Steven Liu wrote:
Signed-off-by: Steven Liu
---
libavformat/flvenc.c | 25 -
1 file changed, 20 insertions(+), 5 deletions(-)
diff --git a/libavformat/flvenc.c b/libavformat/flvenc.c
index 57a26245ff..7b43ecaefa 100644
--- a/libavformat/flvenc.c
+++ b/libavformat/flvenc.c
@@ -28,6 +28,7 @@
#include "libavcodec/mpeg4audio.h"
#include "avio.h"
#include "avc.h"
+#include "av1.h"
#include "hevc.h"
#include "avformat.h"
#include "flv.h"
@@ -48,6 +49,7 @@ static const AVCodecTag flv_video_codec_ids[] = {
{ AV_CODEC_ID_VP6A, FLV_CODECID_VP6A },
{ AV_CODEC_ID_H264, FLV_CODECID_H264 },
{ AV_CODEC_ID_HEVC, MKBETAG('h', 'v', 'c', '1') },
+{ AV_CODEC_ID_AV1, MKBETAG('a', 'v', '0', '1') },
{ AV_CODEC_ID_NONE, 0 }
};
@@ -494,7 +496,8 @@ static void flv_write_codec_header(AVFormatContext* s,
AVCodecParameters* par, i
FLVContext *flv = s->priv_data;
if (par->codec_id == AV_CODEC_ID_AAC || par->codec_id == AV_CODEC_ID_H264
-|| par->codec_id == AV_CODEC_ID_MPEG4 || par->codec_id ==
AV_CODEC_ID_HEVC) {
+|| par->codec_id == AV_CODEC_ID_MPEG4 || par->codec_id ==
AV_CODEC_ID_HEVC
+|| par->codec_id == AV_CODEC_ID_AV1) {
int64_t pos;
avio_w8(pb,
par->codec_type == AVMEDIA_TYPE_VIDEO ?
@@ -540,6 +543,9 @@ static void flv_write_codec_header(AVFormatContext* s,
AVCodecParameters* par, i
if (par->codec_id == AV_CODEC_ID_HEVC) {
avio_w8(pb, FLV_IS_EX_HEADER | PacketTypeSequenceStart); //
ExVideoTagHeader mode with PacketTypeSequenceStart
avio_write(pb, "hvc1", 4);
+} else if (par->codec_id == AV_CODEC_ID_AV1) {
+avio_w8(pb, FLV_IS_EX_HEADER | PacketTypeSequenceStart);
+avio_write(pb, "av01", 4);
} else {
avio_w8(pb, par->codec_tag | FLV_FRAME_KEY); // flags
avio_w8(pb, 0); // AVC sequence header
@@ -548,6 +554,8 @@ static void flv_write_codec_header(AVFormatContext* s,
AVCodecParameters* par, i
if (par->codec_id == AV_CODEC_ID_HEVC)
ff_isom_write_hvcc(pb, par->extradata, par->extradata_size,
0);
+else if (par->codec_id == AV_CODEC_ID_AV1)
+ff_isom_write_av1c(pb, par->extradata, par->extradata_size, 1);
else
ff_isom_write_avcc(pb, par->extradata, par->extradata_size);
}
@@ -640,7 +648,8 @@ static int flv_init(struct AVFormatContext *s)
if (par->codec_id == AV_CODEC_ID_MPEG4 ||
par->codec_id == AV_CODEC_ID_H263 ||
-par->codec_id == AV_CODEC_ID_HEVC) {
+par->codec_id == AV_CODEC_ID_HEVC ||
+par->codec_id == AV_CODEC_ID_AV1) {
int error = s->strict_std_compliance >
FF_COMPLIANCE_UNOFFICIAL;
av_log(s, error ? AV_LOG_ERROR : AV_LOG_WARNING,
"Codec %s is not supported in the official FLV
specification,\n", avcodec_get_name(par->codec_id));
@@ -848,13 +857,15 @@ static int flv_write_packet(AVFormatContext *s, AVPacket
*pkt)
if (par->codec_id == AV_CODEC_ID_VP6F || par->codec_id ==
AV_CODEC_ID_VP6A ||
par->codec_id == AV_CODEC_ID_VP6 || par->codec_id ==
AV_CODEC_ID_AAC)
flags_size = 2;
-else if (par->codec_id == AV_CODEC_ID_H264 || par->codec_id ==
AV_CODEC_ID_MPEG4 || par->codec_id == AV_CODEC_ID_HEVC)
+else if (par->codec_id == AV_CODEC_ID_H264 || par->codec_id ==
AV_CODEC_ID_MPEG4 ||
+ par->codec_id == AV_CODEC_ID_HEVC || par->codec_id ==
AV_CODEC_ID_AV1)
flags_size = 5;
else
flags_size = 1;
if (par->codec_id == AV_CODEC_ID_AAC || par->codec_id == AV_CODEC_ID_H264
-|| par->codec_id == AV_CODEC_ID_MPEG4 || par->codec_id ==
AV_CODEC_ID_HEVC) {
+|| par->codec_id == AV_CODEC_ID_MPEG4 || par->codec_id ==
AV_CODEC_ID_HEVC
+|| par->codec_id == AV_CODEC_ID_AV1) {
size_t side_size;
uint8_t *side = av_packet_get_side_data(pkt, AV_PKT_DATA_NEW_EXTRADATA,
_size);
if (side && side_size > 0 && (side_size != par->extradata_size ||
memcmp(side, par->extradata, side_size))) {
@@ -874,7 +885,8 @@ static int flv_write_packet(AVFormatContext *s, AVPacket
*pkt)
"Packets are not in the proper order with respect to DTS\n");
return AVERROR(EINVAL);
}
-if (par->codec_id == AV_CODEC_ID_H264 || par->codec_id == AV_CODEC_ID_MPEG4
|| par->codec_id == AV_CODEC_ID_HEVC) {
+if (par->codec_id ==
Re: [FFmpeg-devel] [PATCH v8 3/6] avformat/flvenc: support mux av1 in enhanced flv
On Tue, May 9, 2023 at 12:14 AM Gyan Doshi wrote:
>
>
>
> On 2023-05-09 08:11 am, Neal Gompa wrote:
> > On Mon, May 8, 2023 at 9:55 PM Steven Liu wrote:
> >> Neal Gompa 于2023年5月9日周二 07:08写道：
> >>> On Thu, Apr 13, 2023 at 5:45 AM Steven Liu wrote:
> Signed-off-by: Steven Liu
> ---
> libavformat/flvenc.c | 25 -
> 1 file changed, 20 insertions(+), 5 deletions(-)
>
> diff --git a/libavformat/flvenc.c b/libavformat/flvenc.c
> index 57a26245ff..7b43ecaefa 100644
> --- a/libavformat/flvenc.c
> +++ b/libavformat/flvenc.c
> @@ -28,6 +28,7 @@
> #include "libavcodec/mpeg4audio.h"
> #include "avio.h"
> #include "avc.h"
> +#include "av1.h"
> #include "hevc.h"
> #include "avformat.h"
> #include "flv.h"
> @@ -48,6 +49,7 @@ static const AVCodecTag flv_video_codec_ids[] = {
> { AV_CODEC_ID_VP6A, FLV_CODECID_VP6A },
> { AV_CODEC_ID_H264, FLV_CODECID_H264 },
> { AV_CODEC_ID_HEVC, MKBETAG('h', 'v', 'c', '1') },
> +{ AV_CODEC_ID_AV1, MKBETAG('a', 'v', '0', '1') },
> { AV_CODEC_ID_NONE, 0 }
> };
>
> @@ -494,7 +496,8 @@ static void flv_write_codec_header(AVFormatContext*
> s, AVCodecParameters* par, i
> FLVContext *flv = s->priv_data;
>
> if (par->codec_id == AV_CODEC_ID_AAC || par->codec_id ==
> AV_CODEC_ID_H264
> -|| par->codec_id == AV_CODEC_ID_MPEG4 || par->codec_id ==
> AV_CODEC_ID_HEVC) {
> +|| par->codec_id == AV_CODEC_ID_MPEG4 || par->codec_id ==
> AV_CODEC_ID_HEVC
> +|| par->codec_id == AV_CODEC_ID_AV1) {
> int64_t pos;
> avio_w8(pb,
> par->codec_type == AVMEDIA_TYPE_VIDEO ?
> @@ -540,6 +543,9 @@ static void flv_write_codec_header(AVFormatContext*
> s, AVCodecParameters* par, i
> if (par->codec_id == AV_CODEC_ID_HEVC) {
> avio_w8(pb, FLV_IS_EX_HEADER |
> PacketTypeSequenceStart); // ExVideoTagHeader mode with
> PacketTypeSequenceStart
> avio_write(pb, "hvc1", 4);
> +} else if (par->codec_id == AV_CODEC_ID_AV1) {
> +avio_w8(pb, FLV_IS_EX_HEADER | PacketTypeSequenceStart);
> +avio_write(pb, "av01", 4);
> } else {
> avio_w8(pb, par->codec_tag | FLV_FRAME_KEY); // flags
> avio_w8(pb, 0); // AVC sequence header
> @@ -548,6 +554,8 @@ static void flv_write_codec_header(AVFormatContext*
> s, AVCodecParameters* par, i
>
> if (par->codec_id == AV_CODEC_ID_HEVC)
> ff_isom_write_hvcc(pb, par->extradata,
> par->extradata_size, 0);
> +else if (par->codec_id == AV_CODEC_ID_AV1)
> +ff_isom_write_av1c(pb, par->extradata,
> par->extradata_size, 1);
> else
> ff_isom_write_avcc(pb, par->extradata,
> par->extradata_size);
> }
> @@ -640,7 +648,8 @@ static int flv_init(struct AVFormatContext *s)
>
> if (par->codec_id == AV_CODEC_ID_MPEG4 ||
> par->codec_id == AV_CODEC_ID_H263 ||
> -par->codec_id == AV_CODEC_ID_HEVC) {
> +par->codec_id == AV_CODEC_ID_HEVC ||
> +par->codec_id == AV_CODEC_ID_AV1) {
> int error = s->strict_std_compliance >
> FF_COMPLIANCE_UNOFFICIAL;
> av_log(s, error ? AV_LOG_ERROR : AV_LOG_WARNING,
> "Codec %s is not supported in the official FLV
> specification,\n", avcodec_get_name(par->codec_id));
> @@ -848,13 +857,15 @@ static int flv_write_packet(AVFormatContext *s,
> AVPacket *pkt)
> if (par->codec_id == AV_CODEC_ID_VP6F || par->codec_id ==
> AV_CODEC_ID_VP6A ||
> par->codec_id == AV_CODEC_ID_VP6 || par->codec_id ==
> AV_CODEC_ID_AAC)
> flags_size = 2;
> -else if (par->codec_id == AV_CODEC_ID_H264 || par->codec_id ==
> AV_CODEC_ID_MPEG4 || par->codec_id == AV_CODEC_ID_HEVC)
> +else if (par->codec_id == AV_CODEC_ID_H264 || par->codec_id ==
> AV_CODEC_ID_MPEG4 ||
> + par->codec_id == AV_CODEC_ID_HEVC || par->codec_id ==
> AV_CODEC_ID_AV1)
> flags_size = 5;
> else
> flags_size = 1;
>
> if (par->codec_id == AV_CODEC_ID_AAC || par->codec_id ==
> AV_CODEC_ID_H264
> -|| par->codec_id == AV_CODEC_ID_MPEG4 || par->codec_id ==
> AV_CODEC_ID_HEVC) {
> +|| par->codec_id == AV_CODEC_ID_MPEG4 || par->codec_id ==
> AV_CODEC_ID_HEVC
> +||
[FFmpeg-devel] [PATCH 2/3] lavc: deprecate AV_CODEC_CAP_SUBFRAMES
There is nothing meaningful the caller can do with it.
---
libavcodec/alsdec.c | 6 +-
libavcodec/apac.c | 6 --
libavcodec/apedec.c | 6 +-
libavcodec/atrac3.c | 12 ++--
libavcodec/atrac9dec.c | 6 +-
libavcodec/bonk.c | 6 --
libavcodec/codec.h | 3 +++
libavcodec/ftr.c| 6 +-
libavcodec/g723_1dec.c | 6 +-
libavcodec/g729dec.c| 12 ++--
libavcodec/libspeexdec.c| 6 +-
libavcodec/misc4.c | 5 -
libavcodec/shorten.c| 6 --
libavcodec/tests/avcodec.c | 3 +--
libavcodec/version_major.h | 1 +
libavcodec/wavarc.c | 2 ++
libavcodec/wmalosslessdec.c | 6 +-
libavcodec/wmaprodec.c | 18 +++---
libavcodec/wmavoice.c | 6 +-
19 files changed, 98 insertions(+), 24 deletions(-)
diff --git a/libavcodec/alsdec.c b/libavcodec/alsdec.c
index 4605b2248f..c64d1032a4 100644
--- a/libavcodec/alsdec.c
+++ b/libavcodec/alsdec.c
@@ -2190,6 +2190,10 @@ const FFCodec ff_als_decoder = {
.close = decode_end,
FF_CODEC_DECODE_CB(decode_frame),
.flush = flush,
-.p.capabilities = AV_CODEC_CAP_SUBFRAMES | AV_CODEC_CAP_DR1 |
AV_CODEC_CAP_CHANNEL_CONF,
+.p.capabilities =
+#if FF_API_SUBFRAMES
+ AV_CODEC_CAP_SUBFRAMES |
+#endif
+ AV_CODEC_CAP_DR1 | AV_CODEC_CAP_CHANNEL_CONF,
.caps_internal = FF_CODEC_CAP_INIT_CLEANUP,
};
diff --git a/libavcodec/apac.c b/libavcodec/apac.c
index 3408f75292..b6cb6c669e 100644
--- a/libavcodec/apac.c
+++ b/libavcodec/apac.c
@@ -269,8 +269,10 @@ const FFCodec ff_apac_decoder = {
FF_CODEC_DECODE_CB(apac_decode),
.close= apac_close,
.p.capabilities = AV_CODEC_CAP_DELAY |
-AV_CODEC_CAP_DR1 |
-AV_CODEC_CAP_SUBFRAMES,
+#if FF_API_SUBFRAMES
+AV_CODEC_CAP_SUBFRAMES |
+#endif
+AV_CODEC_CAP_DR1,
.caps_internal= FF_CODEC_CAP_INIT_CLEANUP,
.p.sample_fmts= (const enum AVSampleFormat[]) { AV_SAMPLE_FMT_U8P,
AV_SAMPLE_FMT_S16P,
diff --git a/libavcodec/apedec.c b/libavcodec/apedec.c
index 772636afde..613c76df0b 100644
--- a/libavcodec/apedec.c
+++ b/libavcodec/apedec.c
@@ -1680,7 +1680,11 @@ const FFCodec ff_ape_decoder = {
.init = ape_decode_init,
.close = ape_decode_close,
FF_CODEC_DECODE_CB(ape_decode_frame),
-.p.capabilities = AV_CODEC_CAP_SUBFRAMES | AV_CODEC_CAP_DELAY |
+.p.capabilities =
+#if FF_API_SUBFRAMES
+ AV_CODEC_CAP_SUBFRAMES |
+#endif
+ AV_CODEC_CAP_DELAY |
AV_CODEC_CAP_DR1,
.caps_internal = FF_CODEC_CAP_INIT_CLEANUP,
.flush = ape_flush,
diff --git a/libavcodec/atrac3.c b/libavcodec/atrac3.c
index 7415da590b..5851ee027c 100644
--- a/libavcodec/atrac3.c
+++ b/libavcodec/atrac3.c
@@ -1026,7 +1026,11 @@ const FFCodec ff_atrac3_decoder = {
.init = atrac3_decode_init,
.close= atrac3_decode_close,
FF_CODEC_DECODE_CB(atrac3_decode_frame),
-.p.capabilities = AV_CODEC_CAP_SUBFRAMES | AV_CODEC_CAP_DR1,
+.p.capabilities =
+#if FF_API_SUBFRAMES
+AV_CODEC_CAP_SUBFRAMES |
+#endif
+AV_CODEC_CAP_DR1,
.p.sample_fmts= (const enum AVSampleFormat[]) { AV_SAMPLE_FMT_FLTP,
AV_SAMPLE_FMT_NONE },
.caps_internal= FF_CODEC_CAP_INIT_CLEANUP,
@@ -1041,7 +1045,11 @@ const FFCodec ff_atrac3al_decoder = {
.init = atrac3_decode_init,
.close= atrac3_decode_close,
FF_CODEC_DECODE_CB(atrac3al_decode_frame),
-.p.capabilities = AV_CODEC_CAP_SUBFRAMES | AV_CODEC_CAP_DR1,
+.p.capabilities =
+#if FF_API_SUBFRAMES
+AV_CODEC_CAP_SUBFRAMES |
+#endif
+AV_CODEC_CAP_DR1,
.p.sample_fmts= (const enum AVSampleFormat[]) { AV_SAMPLE_FMT_FLTP,
AV_SAMPLE_FMT_NONE },
.caps_internal= FF_CODEC_CAP_INIT_CLEANUP,
diff --git a/libavcodec/atrac9dec.c b/libavcodec/atrac9dec.c
index 60962b1676..8a6940455d 100644
--- a/libavcodec/atrac9dec.c
+++ b/libavcodec/atrac9dec.c
@@ -1003,5 +1003,9 @@ const FFCodec ff_atrac9_decoder = {
FF_CODEC_DECODE_CB(atrac9_decode_frame),
.flush = atrac9_decode_flush,
.caps_internal = FF_CODEC_CAP_INIT_CLEANUP,
-.p.capabilities = AV_CODEC_CAP_SUBFRAMES | AV_CODEC_CAP_DR1 |
AV_CODEC_CAP_CHANNEL_CONF,
+.p.capabilities =
+#if FF_API_SUBFRAMES
+ AV_CODEC_CAP_SUBFRAMES |
+#endif
+ AV_CODEC_CAP_DR1 | AV_CODEC_CAP_CHANNEL_CONF,
};
diff --git a/libavcodec/bonk.c b/libavcodec/bonk.c
index
[FFmpeg-devel] [PATCH 1/3] lavc/decode: drop a useless warning
Decoders will currently warn if an audio decoder not marked with
AV_CODEC_CAP_SUBFRAMES consumes less than the whole packet, but
* this happens for regular files
* this has no negative consequences
* there is no meeaningful action that can or should be taken in response
The warning is thus useless noise.
---
libavcodec/decode.c | 7 ---
libavcodec/internal.h | 2 --
2 files changed, 9 deletions(-)
diff --git a/libavcodec/decode.c b/libavcodec/decode.c
index 4f2359f07e..360837a0ad 100644
--- a/libavcodec/decode.c
+++ b/libavcodec/decode.c
@@ -423,13 +423,6 @@ FF_ENABLE_DEPRECATION_WARNINGS
}
}
-if (avctx->codec->type == AVMEDIA_TYPE_AUDIO &&
-!avci->showed_multi_packet_warning &&
-ret >= 0 && ret != pkt->size && !(avctx->codec->capabilities &
AV_CODEC_CAP_SUBFRAMES)) {
-av_log(avctx, AV_LOG_WARNING, "Multiple frames in a packet.\n");
-avci->showed_multi_packet_warning = 1;
-}
-
if (!got_frame)
av_frame_unref(frame);
diff --git a/libavcodec/internal.h b/libavcodec/internal.h
index a283c52e01..dceae182c0 100644
--- a/libavcodec/internal.h
+++ b/libavcodec/internal.h
@@ -148,8 +148,6 @@ typedef struct AVCodecInternal {
AVFrame *buffer_frame;
int draining_done;
-int showed_multi_packet_warning;
-
/* to prevent infinite loop on errors when draining */
int nb_draining_errors;
--
2.39.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 3/3] fftools/opt_common: stop printing deprecated AV_CODEC_CAP_SUBFRAMES
---
fftools/opt_common.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/fftools/opt_common.c b/fftools/opt_common.c
index 8a06df82df..f6fe9815e1 100644
--- a/fftools/opt_common.c
+++ b/fftools/opt_common.c
@@ -291,8 +291,6 @@ static void print_codec(const AVCodec *c)
printf("delay ");
if (c->capabilities & AV_CODEC_CAP_SMALL_LAST_FRAME)
printf("small ");
-if (c->capabilities & AV_CODEC_CAP_SUBFRAMES)
-printf("subframes ");
if (c->capabilities & AV_CODEC_CAP_EXPERIMENTAL)
printf("exp ");
if (c->capabilities & AV_CODEC_CAP_CHANNEL_CONF)
--
2.39.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] Add functions to identify devices in more ways
> On May 9, 2023, at 12:16, Timo Rothenpieler wrote: > > On 09/05/2023 12:11, rcombs wrote: >> - cuDeviceGetUuid_v2, giving distinct IDs for different MIG instances >> - cuDeviceGetLuid, giving a Win32 LUID to match with DXGI and other APIs >> - cuDeviceGetByPCIBusId, retrieving a device that matches a PCI bus ID string >> - cuDeviceGetPCIBusId, giving a PCI bus ID string for a device > > Looks good to me. What do you need those for? > Interop with D3D1x/Vulkan? I'm fetching device lists with DXGI (windows) or libdrm (linux); these functions seem to be the best way to correlate devices with those APIs. Probably also useful for D3D/Vk interop, though; particularly the v2 UUID function, as my guess is that the Vk interop code is probably broken in MIG mode right now. Would appreciate seeing this backported to the 11.x branches; it applies cleanly. > ___ > 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] Add functions to identify devices in more ways
On 09/05/2023 12:11, rcombs wrote: - cuDeviceGetUuid_v2, giving distinct IDs for different MIG instances - cuDeviceGetLuid, giving a Win32 LUID to match with DXGI and other APIs - cuDeviceGetByPCIBusId, retrieving a device that matches a PCI bus ID string - cuDeviceGetPCIBusId, giving a PCI bus ID string for a device Looks good to me. What do you need those for? Interop with D3D1x/Vulkan? ___ 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] Add functions to identify devices in more ways
- cuDeviceGetUuid_v2, giving distinct IDs for different MIG instances
- cuDeviceGetLuid, giving a Win32 LUID to match with DXGI and other APIs
- cuDeviceGetByPCIBusId, retrieving a device that matches a PCI bus ID string
- cuDeviceGetPCIBusId, giving a PCI bus ID string for a device
---
include/ffnvcodec/dynlink_cuda.h | 4
include/ffnvcodec/dynlink_loader.h | 8
2 files changed, 12 insertions(+)
diff --git a/include/ffnvcodec/dynlink_cuda.h b/include/ffnvcodec/dynlink_cuda.h
index baafa49..d52d793 100644
--- a/include/ffnvcodec/dynlink_cuda.h
+++ b/include/ffnvcodec/dynlink_cuda.h
@@ -355,6 +355,10 @@ typedef CUresult CUDAAPI tcuDeviceGet(CUdevice *device,
int ordinal);
typedef CUresult CUDAAPI tcuDeviceGetAttribute(int *pi, CUdevice_attribute
attrib, CUdevice dev);
typedef CUresult CUDAAPI tcuDeviceGetName(char *name, int len, CUdevice dev);
typedef CUresult CUDAAPI tcuDeviceGetUuid(CUuuid *uuid, CUdevice dev);
+typedef CUresult CUDAAPI tcuDeviceGetUuid_v2(CUuuid *uuid, CUdevice dev);
+typedef CUresult CUDAAPI tcuDeviceGetLuid(char* luid, unsigned int*
deviceNodeMask, CUdevice dev);
+typedef CUresult CUDAAPI tcuDeviceGetByPCIBusId(CUdevice* dev, const char*
pciBusId);
+typedef CUresult CUDAAPI tcuDeviceGetPCIBusId(char* pciBusId, int len,
CUdevice dev);
typedef CUresult CUDAAPI tcuDeviceComputeCapability(int *major, int *minor,
CUdevice dev);
typedef CUresult CUDAAPI tcuCtxCreate_v2(CUcontext *pctx, unsigned int flags,
CUdevice dev);
typedef CUresult CUDAAPI tcuCtxSetLimit(CUlimit limit, size_t value);
diff --git a/include/ffnvcodec/dynlink_loader.h
b/include/ffnvcodec/dynlink_loader.h
index 85aebf4..14d17e3 100644
--- a/include/ffnvcodec/dynlink_loader.h
+++ b/include/ffnvcodec/dynlink_loader.h
@@ -142,6 +142,10 @@ typedef struct CudaFunctions {
tcuDeviceGetAttribute *cuDeviceGetAttribute;
tcuDeviceGetName *cuDeviceGetName;
tcuDeviceGetUuid *cuDeviceGetUuid;
+tcuDeviceGetUuid_v2 *cuDeviceGetUuid_v2;
+tcuDeviceGetLuid *cuDeviceGetLuid;
+tcuDeviceGetByPCIBusId *cuDeviceGetByPCIBusId;
+tcuDeviceGetPCIBusId *cuDeviceGetPCIBusId;
tcuDeviceComputeCapability *cuDeviceComputeCapability;
tcuCtxCreate_v2 *cuCtxCreate;
tcuCtxSetLimit *cuCtxSetLimit;
@@ -337,6 +341,10 @@ static inline int cuda_load_functions(CudaFunctions
**functions, void *logctx)
LOAD_SYMBOL(cuGraphicsSubResourceGetMappedArray,
tcuGraphicsSubResourceGetMappedArray, "cuGraphicsSubResourceGetMappedArray");
LOAD_SYMBOL_OPT(cuDeviceGetUuid, tcuDeviceGetUuid, "cuDeviceGetUuid");
+LOAD_SYMBOL_OPT(cuDeviceGetUuid_v2, tcuDeviceGetUuid_v2,
"cuDeviceGetUuid_v2");
+LOAD_SYMBOL_OPT(cuDeviceGetLuid, tcuDeviceGetLuid, "cuDeviceGetLuid");
+LOAD_SYMBOL_OPT(cuDeviceGetByPCIBusId, tcuDeviceGetByPCIBusId,
"cuDeviceGetByPCIBusId");
+LOAD_SYMBOL_OPT(cuDeviceGetPCIBusId, tcuDeviceGetPCIBusId,
"cuDeviceGetPCIBusId");
LOAD_SYMBOL_OPT(cuImportExternalMemory, tcuImportExternalMemory,
"cuImportExternalMemory");
LOAD_SYMBOL_OPT(cuDestroyExternalMemory, tcuDestroyExternalMemory,
"cuDestroyExternalMemory");
LOAD_SYMBOL_OPT(cuExternalMemoryGetMappedBuffer,
tcuExternalMemoryGetMappedBuffer, "cuExternalMemoryGetMappedBuffer");
--
2.39.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2] avutil: deprecate AVRational field inside AVOption::default_val
tis 2023-05-02 klockan 08:39 -0300 skrev James Almer:
> On 5/2/2023 8:34 AM, Tomas Härdin wrote:
> > tis 2023-05-02 klockan 15:48 +0800 skrev Zhao Zhili:
> > > From: Zhao Zhili
> > >
> > > Signed-off-by: Zhao Zhili
> > > ---
> > > libavutil/opt.h | 2 ++
> > > libavutil/version.h | 1 +
> > > 2 files changed, 3 insertions(+)
> > >
> > > diff --git a/libavutil/opt.h b/libavutil/opt.h
> > > index 461b5d3b6b..46915754ea 100644
> > > --- a/libavutil/opt.h
> > > +++ b/libavutil/opt.h
> > > @@ -271,8 +271,10 @@ typedef struct AVOption {
> > > int64_t i64;
> > > double dbl;
> > > const char *str;
> > > +#if FF_API_AVOPTION_AVRATIONAL
> > > /* TODO those are unused now */
> > > AVRational q;
> > > +#endif
> >
> > Surely rationals options are useful?
>
> They are, but this union is where the default value is stored when
> you
> define an AVOption. At some point it seems it was decided that
> rational
> (and video_rate) type AVOptions should set dbl instead of q, which is
> then av_q2d()'d into an AVRational.
Cursed and very wrong in many contexts
/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] avutil/imgutils: optimize image copying
fre 2023-05-05 klockan 16:31 +0800 skrev xufuji456: > It makes sense when copying 4K/8K video frame, got 2.7% speed up. > When the condition is no padding and src_linesize equals to dst, > we could copy plane instead of line by line. > before after rate > 4K video: > 9145 8998 1.6% > 9804 9465 3.4% > 9645 9394 2.6% > 8K video: > 28411 27718 2.4% > 31288 30056 3.9% > 32336 31571 2.4% > > Signed-off-by: xufuji456 <839789...@qq.com> > --- > libavutil/imgutils.c | 16 > 1 file changed, 12 insertions(+), 4 deletions(-) Nice, looks OK to me /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".
[FFmpeg-devel] [PATCH 5/5] lavc/h264pred: Add vectorized implementation of intra prediction for RISC-V
Optimize intra prediction using RISC-V vector intrinsics.
Although the intra prediction in the decoder is not a computational hotspot,
the FPS has further improved by 1% after vectorizing this part, as measured on
720P videos.
Signed-off-by: Arnie Chang
---
libavcodec/h264pred.c | 2 +
libavcodec/h264pred.h | 3 +-
libavcodec/riscv/Makefile | 2 +
libavcodec/riscv/h264_pred.c| 884
libavcodec/riscv/h264_pred.h| 53 ++
libavcodec/riscv/h264_pred_init_riscv.c | 67 ++
6 files changed, 1010 insertions(+), 1 deletion(-)
create mode 100644 libavcodec/riscv/h264_pred.c
create mode 100644 libavcodec/riscv/h264_pred.h
create mode 100644 libavcodec/riscv/h264_pred_init_riscv.c
diff --git a/libavcodec/h264pred.c b/libavcodec/h264pred.c
index 25f9995a0b..f4ad02c326 100644
--- a/libavcodec/h264pred.c
+++ b/libavcodec/h264pred.c
@@ -598,5 +598,7 @@ av_cold void ff_h264_pred_init(H264PredContext *h, int
codec_id,
ff_h264_pred_init_mips(h, codec_id, bit_depth, chroma_format_idc);
#elif ARCH_LOONGARCH
ff_h264_pred_init_loongarch(h, codec_id, bit_depth, chroma_format_idc);
+#elif ARCH_RISCV
+ff_h264_pred_init_riscv(h, codec_id, bit_depth, chroma_format_idc);
#endif
}
diff --git a/libavcodec/h264pred.h b/libavcodec/h264pred.h
index cb008548fc..8ac5088b34 100644
--- a/libavcodec/h264pred.h
+++ b/libavcodec/h264pred.h
@@ -126,5 +126,6 @@ void ff_h264_pred_init_mips(H264PredContext *h, int
codec_id,
const int bit_depth, const int chroma_format_idc);
void ff_h264_pred_init_loongarch(H264PredContext *h, int codec_id,
const int bit_depth, const int
chroma_format_idc);
-
+void ff_h264_pred_init_riscv(H264PredContext *h, int codec_id,
+ const int bit_depth, const int chroma_format_idc);
#endif /* AVCODEC_H264PRED_H */
diff --git a/libavcodec/riscv/Makefile b/libavcodec/riscv/Makefile
index 4d54bf35e9..9f7d7289f3 100644
--- a/libavcodec/riscv/Makefile
+++ b/libavcodec/riscv/Makefile
@@ -28,3 +28,5 @@ OBJS-$(CONFIG_H264DSP) += riscv/h264_dsp_init_riscv.o
RVV-OBJS-$(CONFIG_H264DSP) += riscv/h264_weighted_sum.o
RVV-OBJS-$(CONFIG_H264DSP) += riscv/h264_inloop.o
RVV-OBJS-$(CONFIG_H264DSP) += riscv/h264_idct.o
+OBJS-$(CONFIG_H264PRED) += riscv/h264_pred_init_riscv.o
+RVV-OBJS-$(CONFIG_H264PRED) += riscv/h264_pred.o
diff --git a/libavcodec/riscv/h264_pred.c b/libavcodec/riscv/h264_pred.c
new file mode 100644
index 00..0ba114d906
--- /dev/null
+++ b/libavcodec/riscv/h264_pred.c
@@ -0,0 +1,884 @@
+/*
+ * Copyright (c) 2023 SiFive, Inc. All rights reserved.
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include "h264_pred.h"
+
+#if HAVE_INTRINSICS_RVV
+#include
+void pred8x8_vert_8_rvv(uint8_t *p_src, ptrdiff_t stride)
+{
+uint8_t *p_src_iter = p_src;
+int width = 8;
+
+while (width > 0)
+{
+int vl = __riscv_vsetvl_e8m1(width);
+uint8_t *p_src_iter_next = p_src_iter + vl;
+
+vuint8m1_t top = __riscv_vle8_v_u8m1(p_src_iter - stride, vl);
+
+__riscv_vse8_v_u8m1(p_src_iter, top, vl);
+p_src_iter += stride;
+__riscv_vse8_v_u8m1(p_src_iter, top, vl);
+p_src_iter += stride;
+__riscv_vse8_v_u8m1(p_src_iter, top, vl);
+p_src_iter += stride;
+__riscv_vse8_v_u8m1(p_src_iter, top, vl);
+p_src_iter += stride;
+__riscv_vse8_v_u8m1(p_src_iter, top, vl);
+p_src_iter += stride;
+__riscv_vse8_v_u8m1(p_src_iter, top, vl);
+p_src_iter += stride;
+__riscv_vse8_v_u8m1(p_src_iter, top, vl);
+p_src_iter += stride;
+__riscv_vse8_v_u8m1(p_src_iter, top, vl);
+p_src_iter += stride;
+
+width -= vl;
+p_src_iter = p_src_iter_next;
+}
+}
+
+void pred8x8_hor_8_rvv(uint8_t *p_src, ptrdiff_t stride)
+{
+uint8_t *p_src_iter = p_src;
+int width = 8;
+
+while (width > 0)
+{
+int vl = __riscv_vsetvl_e8m1(width);
+vuint8m1_t left = __riscv_vlse8_v_u8m1(p_src_iter - 1, stride, width);
+
+__riscv_vssseg8e8_v_u8m1(p_src_iter, stride, left, left, left, left,
left, left, left, left, width);
+
+
[FFmpeg-devel] [PATCH 4/5] lavc/h264dsp: Add vectorized implementation of DSP functions for RISC-V
Optimize IDCT, inloop filtering, and weighed prediction using RISC-V intrinsics.
The performance is elvaluated using 720P videos.
Combine with previous optimizations(chroma and luma MC), the FPS is 2.08x
faster than the scalar one,
while applying only previous optimizations resulted in a speedup of 1.49x.
Signed-off-by: Arnie Chang
---
libavcodec/h264dsp.c | 2 +
libavcodec/h264dsp.h | 3 +-
libavcodec/riscv/Makefile | 4 +
libavcodec/riscv/h264_dsp_init_riscv.c | 68 +++
libavcodec/riscv/h264_idct.c | 482 ++
libavcodec/riscv/h264_idct.h | 46 ++
libavcodec/riscv/h264_inloop.c | 669 +
libavcodec/riscv/h264_inloop.h | 47 ++
libavcodec/riscv/h264_weighted_sum.c | 273 ++
libavcodec/riscv/h264_weighted_sum.h | 47 ++
10 files changed, 1640 insertions(+), 1 deletion(-)
create mode 100644 libavcodec/riscv/h264_dsp_init_riscv.c
create mode 100644 libavcodec/riscv/h264_idct.c
create mode 100644 libavcodec/riscv/h264_idct.h
create mode 100644 libavcodec/riscv/h264_inloop.c
create mode 100644 libavcodec/riscv/h264_inloop.h
create mode 100644 libavcodec/riscv/h264_weighted_sum.c
create mode 100644 libavcodec/riscv/h264_weighted_sum.h
diff --git a/libavcodec/h264dsp.c b/libavcodec/h264dsp.c
index 4d2ee10bab..b6e45c15ef 100644
--- a/libavcodec/h264dsp.c
+++ b/libavcodec/h264dsp.c
@@ -164,5 +164,7 @@ av_cold void ff_h264dsp_init(H264DSPContext *c, const int
bit_depth,
ff_h264dsp_init_mips(c, bit_depth, chroma_format_idc);
#elif ARCH_LOONGARCH
ff_h264dsp_init_loongarch(c, bit_depth, chroma_format_idc);
+#elif ARCH_RISCV
+ff_h264dsp_init_riscv(c, bit_depth, chroma_format_idc);
#endif
}
diff --git a/libavcodec/h264dsp.h b/libavcodec/h264dsp.h
index e0880c4d88..f2f8aa7e60 100644
--- a/libavcodec/h264dsp.h
+++ b/libavcodec/h264dsp.h
@@ -131,5 +131,6 @@ void ff_h264dsp_init_mips(H264DSPContext *c, const int
bit_depth,
const int chroma_format_idc);
void ff_h264dsp_init_loongarch(H264DSPContext *c, const int bit_depth,
const int chroma_format_idc);
-
+void ff_h264dsp_init_riscv(H264DSPContext *c, const int bit_depth,
+ const int chroma_format_idc);
#endif /* AVCODEC_H264DSP_H */
diff --git a/libavcodec/riscv/Makefile b/libavcodec/riscv/Makefile
index 088efa3b1e..4d54bf35e9 100644
--- a/libavcodec/riscv/Makefile
+++ b/libavcodec/riscv/Makefile
@@ -24,3 +24,7 @@ OBJS-$(CONFIG_H264CHROMA) += riscv/h264_chroma_init_riscv.o
RVV-OBJS-$(CONFIG_H264CHROMA) += riscv/h264_mc_chroma.o
OBJS-$(CONFIG_H264QPEL) += riscv/h264_qpel_init_riscv.o
RVV-OBJS-$(CONFIG_H264QPEL) += riscv/h264_mc_luma.o
+OBJS-$(CONFIG_H264DSP) += riscv/h264_dsp_init_riscv.o
+RVV-OBJS-$(CONFIG_H264DSP) += riscv/h264_weighted_sum.o
+RVV-OBJS-$(CONFIG_H264DSP) += riscv/h264_inloop.o
+RVV-OBJS-$(CONFIG_H264DSP) += riscv/h264_idct.o
diff --git a/libavcodec/riscv/h264_dsp_init_riscv.c
b/libavcodec/riscv/h264_dsp_init_riscv.c
new file mode 100644
index 00..7d41aa98a5
--- /dev/null
+++ b/libavcodec/riscv/h264_dsp_init_riscv.c
@@ -0,0 +1,68 @@
+/*
+ * Copyright (c) 2023 SiFive, Inc. All rights reserved.
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include
+#include "libavutil/attributes.h"
+#include "libavutil/cpu.h"
+#include "libavcodec/h264dsp.h"
+#include "config.h"
+#include "h264_inloop.h"
+#include "h264_weighted_sum.h"
+#include "h264_idct.h"
+
+av_cold void ff_h264dsp_init_riscv(H264DSPContext *c, const int bit_depth,
const int chroma_format_idc)
+{
+#if HAVE_INTRINSICS_RVV
+if (bit_depth == 8) {
+c->h264_v_loop_filter_luma = h264_v_loop_filter_luma_8_rvv;
+c->h264_v_loop_filter_luma_intra= h264_v_loop_filter_luma_intra_8_rvv;
+
+c->h264_h_loop_filter_luma = h264_h_loop_filter_luma_8_rvv;
+c->h264_h_loop_filter_luma_intra= h264_h_loop_filter_luma_intra_8_rvv;
+
+c->h264_v_loop_filter_chroma = h264_v_loop_filter_chroma_8_rvv;
+c->h264_v_loop_filter_chroma_intra =
h264_v_loop_filter_chroma_intra_8_rvv;
+
+if (chroma_format_idc <= 1) {
+c->h264_h_loop_filter_chroma =
[FFmpeg-devel] [PATCH 2/5] lavc/h264chroma: Add vectorized implementation of chroma MC for RISC-V
Optimize chroma motion compensation using RISC-V vector intrinsics,
resulting in an average 13% FPS improvement on 720P videos.
Signed-off-by: Arnie Chang
---
libavcodec/h264chroma.c | 2 +
libavcodec/h264chroma.h | 1 +
libavcodec/riscv/Makefile | 3 +
libavcodec/riscv/h264_chroma_init_riscv.c | 45 ++
libavcodec/riscv/h264_mc_chroma.c | 821 ++
libavcodec/riscv/h264_mc_chroma.h | 40 ++
6 files changed, 912 insertions(+)
create mode 100644 libavcodec/riscv/h264_chroma_init_riscv.c
create mode 100644 libavcodec/riscv/h264_mc_chroma.c
create mode 100644 libavcodec/riscv/h264_mc_chroma.h
diff --git a/libavcodec/h264chroma.c b/libavcodec/h264chroma.c
index 60b86b6fba..1eeab7bc40 100644
--- a/libavcodec/h264chroma.c
+++ b/libavcodec/h264chroma.c
@@ -58,5 +58,7 @@ av_cold void ff_h264chroma_init(H264ChromaContext *c, int
bit_depth)
ff_h264chroma_init_mips(c, bit_depth);
#elif ARCH_LOONGARCH64
ff_h264chroma_init_loongarch(c, bit_depth);
+#elif ARCH_RISCV
+ff_h264chroma_init_riscv(c, bit_depth);
#endif
}
diff --git a/libavcodec/h264chroma.h b/libavcodec/h264chroma.h
index b8f9c8f4fc..9c81c18a76 100644
--- a/libavcodec/h264chroma.h
+++ b/libavcodec/h264chroma.h
@@ -37,5 +37,6 @@ void ff_h264chroma_init_ppc(H264ChromaContext *c, int
bit_depth);
void ff_h264chroma_init_x86(H264ChromaContext *c, int bit_depth);
void ff_h264chroma_init_mips(H264ChromaContext *c, int bit_depth);
void ff_h264chroma_init_loongarch(H264ChromaContext *c, int bit_depth);
+void ff_h264chroma_init_riscv(H264ChromaContext *c, int bit_depth);
#endif /* AVCODEC_H264CHROMA_H */
diff --git a/libavcodec/riscv/Makefile b/libavcodec/riscv/Makefile
index 965942f4df..08b76c93cb 100644
--- a/libavcodec/riscv/Makefile
+++ b/libavcodec/riscv/Makefile
@@ -19,3 +19,6 @@ OBJS-$(CONFIG_PIXBLOCKDSP) += riscv/pixblockdsp_init.o \
RVV-OBJS-$(CONFIG_PIXBLOCKDSP) += riscv/pixblockdsp_rvv.o
OBJS-$(CONFIG_VORBIS_DECODER) += riscv/vorbisdsp_init.o
RVV-OBJS-$(CONFIG_VORBIS_DECODER) += riscv/vorbisdsp_rvv.o
+
+OBJS-$(CONFIG_H264CHROMA) += riscv/h264_chroma_init_riscv.o
+RVV-OBJS-$(CONFIG_H264CHROMA) += riscv/h264_mc_chroma.o
diff --git a/libavcodec/riscv/h264_chroma_init_riscv.c
b/libavcodec/riscv/h264_chroma_init_riscv.c
new file mode 100644
index 00..daeca01fa2
--- /dev/null
+++ b/libavcodec/riscv/h264_chroma_init_riscv.c
@@ -0,0 +1,45 @@
+/*
+ * Copyright (c) 2023 SiFive, Inc. All rights reserved.
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include
+
+#include "libavutil/attributes.h"
+#include "libavutil/cpu.h"
+#include "libavcodec/h264chroma.h"
+#include "config.h"
+#include "h264_mc_chroma.h"
+
+av_cold void ff_h264chroma_init_riscv(H264ChromaContext *c, int bit_depth)
+{
+#if HAVE_INTRINSICS_RVV
+const int high_bit_depth = bit_depth > 8;
+
+if (!high_bit_depth) {
+c->put_h264_chroma_pixels_tab[0] = h264_put_chroma_mc8_rvv;
+c->avg_h264_chroma_pixels_tab[0] = h264_avg_chroma_mc8_rvv;
+
+c->put_h264_chroma_pixels_tab[1] = h264_put_chroma_mc4_rvv;
+c->avg_h264_chroma_pixels_tab[1] = h264_avg_chroma_mc4_rvv;
+
+c->put_h264_chroma_pixels_tab[2] = h264_put_chroma_mc2_rvv;
+c->avg_h264_chroma_pixels_tab[2] = h264_avg_chroma_mc2_rvv;
+}
+#endif
+}
\ No newline at end of file
diff --git a/libavcodec/riscv/h264_mc_chroma.c
b/libavcodec/riscv/h264_mc_chroma.c
new file mode 100644
index 00..64b13ec3b8
--- /dev/null
+++ b/libavcodec/riscv/h264_mc_chroma.c
@@ -0,0 +1,821 @@
+/*
+ * Copyright (c) 2023 SiFive, Inc. All rights reserved.
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser
[FFmpeg-devel] [PATCH 1/5] configure: Add detection of RISC-V vector intrinsic support
Check whether the toolchain has support for RISC-V intrinsic and then update the flag, HAVE_INTRINSICS_RVV, in the config.h Signed-off-by: Arnie Chang --- configure | 2 ++ 1 file changed, 2 insertions(+) diff --git a/configure b/configure index bb7be67676..883bee1e34 100755 --- a/configure +++ b/configure @@ -2210,6 +2210,7 @@ HEADERS_LIST=" INTRINSICS_LIST=" intrinsics_neon +intrinsics_rvv " MATH_FUNCS=" @@ -6119,6 +6120,7 @@ elif enabled ppc; then elif enabled riscv; then enabled rvv && check_inline_asm rvv '".option arch, +v\nvsetivli zero, 0, e8, m1, ta, ma"' +enabled rvv && check_cc intrinsics_rvv riscv_vector.h "int vl = __riscv_vsetvl_e8m1(8)" elif enabled x86; then -- 2.17.1 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 0/5] RISC-V: Improve H264 decoding performance using RVV intrinsic
We are submitting a set of patches that significantly improve H.264 decoding performance by utilizing RVV intrinsic code. The average speedup(FPS) achieved by these patches is more than 2x, as experimented on 720P videos running on an internal FPGA board. Patch1: add support for RVV intrinsic code in the configure file Patch2: optimize chroma motion compensation Patch3: optimize luma motion compensation Patch4: optimize dsp functions, such as IDCT, in-loop filtering, and weighed filtering Patch5: optimize intra prediction Arnie Chang (5): configure: Add detection of RISC-V vector intrinsic support lavc/h264chroma: Add vectorized implementation of chroma MC for RISC-V lavc/h264qpel: Add vectorized implementation of luma MC for RISC-V lavc/h264dsp: Add vectorized implementation of DSP functions for RISC-V lavc/h264pred: Add vectorized implementation of intra prediction for RISC-V configure |2 + libavcodec/h264chroma.c |2 + libavcodec/h264chroma.h |1 + libavcodec/h264dsp.c |2 + libavcodec/h264dsp.h |3 +- libavcodec/h264pred.c |2 + libavcodec/h264pred.h |3 +- libavcodec/h264qpel.c |2 + libavcodec/h264qpel.h |1 + libavcodec/riscv/Makefile | 11 + libavcodec/riscv/h264_chroma_init_riscv.c | 45 + libavcodec/riscv/h264_dsp_init_riscv.c| 68 ++ libavcodec/riscv/h264_idct.c | 482 + libavcodec/riscv/h264_idct.h | 46 + libavcodec/riscv/h264_inloop.c| 669 libavcodec/riscv/h264_inloop.h| 47 + libavcodec/riscv/h264_lowpass.h | 249 + libavcodec/riscv/h264_mc_chroma.c | 821 ++ libavcodec/riscv/h264_mc_chroma.h | 40 + libavcodec/riscv/h264_mc_luma.c | 412 +++ libavcodec/riscv/h264_mc_luma.h | 101 ++ libavcodec/riscv/h264_mc_luma_avg16.h | 1183 + libavcodec/riscv/h264_mc_luma_avg8.h | 773 ++ libavcodec/riscv/h264_mc_luma_put16.h | 963 + libavcodec/riscv/h264_mc_luma_put8.h | 648 +++ libavcodec/riscv/h264_pred.c | 884 +++ libavcodec/riscv/h264_pred.h | 53 + libavcodec/riscv/h264_pred_init_riscv.c | 67 ++ libavcodec/riscv/h264_qpel_init_riscv.c | 107 ++ libavcodec/riscv/h264_utility.h | 75 ++ libavcodec/riscv/h264_weighted_sum.c | 273 + libavcodec/riscv/h264_weighted_sum.h | 47 + 32 files changed, 8080 insertions(+), 2 deletions(-) create mode 100644 libavcodec/riscv/h264_chroma_init_riscv.c create mode 100644 libavcodec/riscv/h264_dsp_init_riscv.c create mode 100644 libavcodec/riscv/h264_idct.c create mode 100644 libavcodec/riscv/h264_idct.h create mode 100644 libavcodec/riscv/h264_inloop.c create mode 100644 libavcodec/riscv/h264_inloop.h create mode 100644 libavcodec/riscv/h264_lowpass.h create mode 100644 libavcodec/riscv/h264_mc_chroma.c create mode 100644 libavcodec/riscv/h264_mc_chroma.h create mode 100644 libavcodec/riscv/h264_mc_luma.c create mode 100644 libavcodec/riscv/h264_mc_luma.h create mode 100644 libavcodec/riscv/h264_mc_luma_avg16.h create mode 100644 libavcodec/riscv/h264_mc_luma_avg8.h create mode 100644 libavcodec/riscv/h264_mc_luma_put16.h create mode 100644 libavcodec/riscv/h264_mc_luma_put8.h create mode 100644 libavcodec/riscv/h264_pred.c create mode 100644 libavcodec/riscv/h264_pred.h create mode 100644 libavcodec/riscv/h264_pred_init_riscv.c create mode 100644 libavcodec/riscv/h264_qpel_init_riscv.c create mode 100644 libavcodec/riscv/h264_utility.h create mode 100644 libavcodec/riscv/h264_weighted_sum.c create mode 100644 libavcodec/riscv/h264_weighted_sum.h -- 2.17.1 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] MXF - Add jpeg2000 subdescriptor - Sponsored by INA
> +if (j2k_ncomponents != component_count) {
> +av_log(s, AV_LOG_ERROR, "Incoherence about components image
> number.\n");
> +}
I still think you should error out here, since mismatched component
count is indicative of broken internal logic
/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] Add support for animated WebP
Am 09.05.23 um 04:31 schrieb James Zern: On Fri, May 5, 2023 at 10:47 AM Thilo Borgmann wrote: Am 27.04.23 um 20:08 schrieb Thilo Borgmann: Hi, support for animated WebP had been proposed twice in the past [1][2]. This did stall when Lynne called for some review on the demuxer in [1]. So these are the rebased patches from [1], pinging especially for demuxer review. Retested decoding with all files given in #4907. Demuxer needs testing, I just rebased it. Ping. https://googlefonts.github.io/noto-emoji-animation/ is another source of animations. They may provide some useful disposal rectangles and alpha. thanks, will extend the test cases. Maybe there is also a useful addition to FATE from that. Unrelated to those I'll send you an image that hangs ffplay/ffmpeg. Did these patches need an update after you got rid of the conflict markers? I got it, thanks! I had no problems with the test vectors from #4907, though of course I can't be sure. I will try to fix the issue with the hanging file and split the patchset more granular to address Anton's remark as well. Thanks! Thilo [1] https://lists.ffmpeg.org/pipermail/ffmpeg-devel/2020-September/269584.html [2] https://lists.ffmpeg.org/pipermail/ffmpeg-devel/2021-September/285204.html ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v2 11/13] lavc/libvpxenc: send frame durations to the encoder
Adapt similar code from libaomenc - stop using ticks_per_frame except as
a last resort.
---
libavcodec/libvpxenc.c | 15 +--
1 file changed, 13 insertions(+), 2 deletions(-)
diff --git a/libavcodec/libvpxenc.c b/libavcodec/libvpxenc.c
index a20e949842..f70cc87c41 100644
--- a/libavcodec/libvpxenc.c
+++ b/libavcodec/libvpxenc.c
@@ -1692,6 +1692,7 @@ static int vpx_encode(AVCodecContext *avctx, AVPacket
*pkt,
const struct vpx_codec_enc_cfg *enccfg = ctx->encoder.config.enc;
vpx_svc_layer_id_t layer_id;
int layer_id_valid = 0;
+unsigned long duration = 0;
if (avctx->qmax >= 0 && enccfg->rc_max_quantizer != avctx->qmax) {
struct vpx_codec_enc_cfg cfg = *enccfg;
@@ -1820,8 +1821,18 @@ static int vpx_encode(AVCodecContext *avctx, AVPacket
*pkt,
#endif
}
+if (frame && frame->duration > ULONG_MAX) {
+av_log(avctx, AV_LOG_WARNING,
+ "Frame duration too large: %"PRId64"\n", frame->duration);
+} else if (frame && frame->duration)
+duration = frame->duration;
+else if (avctx->framerate.num > 0 && avctx->framerate.den > 0)
+duration = av_rescale_q(1, av_inv_q(avctx->framerate),
avctx->time_base);
+else
+duration = avctx->ticks_per_frame ? avctx->ticks_per_frame : 1;
+
res = vpx_codec_encode(>encoder, rawimg, timestamp,
- avctx->ticks_per_frame, flags, ctx->deadline);
+ duration, flags, ctx->deadline);
if (res != VPX_CODEC_OK) {
log_encoder_error(avctx, "Error encoding frame");
return AVERROR_INVALIDDATA;
@@ -1829,7 +1840,7 @@ static int vpx_encode(AVCodecContext *avctx, AVPacket
*pkt,
if (ctx->is_alpha) {
res = vpx_codec_encode(>encoder_alpha, rawimg_alpha, timestamp,
- avctx->ticks_per_frame, flags, ctx->deadline);
+ duration, flags, ctx->deadline);
if (res != VPX_CODEC_OK) {
log_encoder_error(avctx, "Error encoding alpha frame");
return AVERROR_INVALIDDATA;
--
2.39.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 04/13] lavf: use AV_CODEC_PROP_FIELDS where appropriate
Quoting Michael Niedermayer (2023-05-08 16:15:42) > On Sun, May 07, 2023 at 03:32:46PM +0200, Anton Khirnov wrote: > > H.264 and mpeg12 parsers need to be adjusted at the same time to stop > > using the value of AVCodecContext.ticks_per_frame, because it is not set > > correctly unless the codec has been opened. Previously this would result > > in both the parser and lavf seeing the same incorrect value, which would > > cancel out. > > Updating lavf and not the parsers would result in correct value in lavf, > > but the wrong one in parsers, which would break some tests. > > --- > > libavcodec/h264_parser.c | 4 ++-- > > libavcodec/mpegvideo_parser.c | 2 +- > > libavformat/avformat.c| 9 ++--- > > libavformat/demux.c | 29 +++-- > > libavformat/internal.h| 3 +++ > > 5 files changed, 31 insertions(+), 16 deletions(-) > > Doesnt this sort of change need a major ABI bump ? > it sounds like lavc and lavf interdepend here both ways No, we do not guarantee bug compatibility. Libavformat seeing ticks_per_frame=1 for codecs that set it to 2 upon being opened is a bug. Same for the parser. It just so happens that libavformat AND its internal parser instance see the same incorrect value and this cancels out in cases that are tested by FATE (it would break if we had more thorough tests for repeating single fields). I could split this into two patches, the first of which would fix one of the bugs, expose the other one, breaking some tests. Then the second patch would fix the second bug, fixing the tests again. It seems better to do it in a single step to avoid the noise. -- Anton Khirnov ___ 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 04/13] lavf: use AV_CODEC_PROP_FIELDS where appropriate
H.264 and mpeg12 parsers need to be adjusted at the same time to stop
using the value of AVCodecContext.ticks_per_frame, because it is not set
correctly unless the codec has been opened. Previously this would result
in both the parser and lavf seeing the same incorrect value, which would
cancel out.
Updating lavf and not the parsers would result in correct value in lavf,
but the wrong one in parsers, which would break some tests.
---
libavcodec/h264_parser.c | 4 ++--
libavcodec/mpegvideo_parser.c | 2 +-
libavformat/avformat.c| 9 ++---
libavformat/demux.c | 35 ---
libavformat/internal.h| 3 +++
5 files changed, 32 insertions(+), 21 deletions(-)
diff --git a/libavcodec/h264_parser.c b/libavcodec/h264_parser.c
index 46134a1c48..43abc45f9c 100644
--- a/libavcodec/h264_parser.c
+++ b/libavcodec/h264_parser.c
@@ -568,7 +568,7 @@ static inline int parse_nal_units(AVCodecParserContext *s,
if (p->sei.common.unregistered.x264_build < 44U)
den *= 2;
av_reduce(>framerate.den, >framerate.num,
- sps->num_units_in_tick * avctx->ticks_per_frame,
den, 1 << 30);
+ sps->num_units_in_tick * 2, den, 1 << 30);
}
av_freep(_buffer);
@@ -625,7 +625,7 @@ static int h264_parse(AVCodecParserContext *s,
parse_nal_units(s, avctx, buf, buf_size);
if (avctx->framerate.num)
-time_base = av_inv_q(av_mul_q(avctx->framerate,
(AVRational){avctx->ticks_per_frame, 1}));
+time_base = av_inv_q(av_mul_q(avctx->framerate, (AVRational){2, 1}));
if (p->sei.picture_timing.cpb_removal_delay >= 0) {
s->dts_sync_point= p->sei.buffering_period.present;
s->dts_ref_dts_delta = p->sei.picture_timing.cpb_removal_delay;
diff --git a/libavcodec/mpegvideo_parser.c b/libavcodec/mpegvideo_parser.c
index 8e7e88ff25..08e5316960 100644
--- a/libavcodec/mpegvideo_parser.c
+++ b/libavcodec/mpegvideo_parser.c
@@ -129,6 +129,7 @@ static void mpegvideo_extract_headers(AVCodecParserContext
*s,
s->pict_type = (buf[1] >> 3) & 7;
if (bytes_left >= 4)
vbv_delay = ((buf[1] & 0x07) << 13) | (buf[2] << 5) |
(buf[3] >> 3);
+s->repeat_pict = 1;
}
break;
case SEQ_START_CODE:
@@ -186,7 +187,6 @@ static void mpegvideo_extract_headers(AVCodecParserContext
*s,
progressive_frame = buf[4] & (1 << 7);
/* check if we must repeat the frame */
-s->repeat_pict = 1;
if (repeat_first_field) {
if (pc->progressive_sequence) {
if (top_field_first)
diff --git a/libavformat/avformat.c b/libavformat/avformat.c
index 708d90b38c..fea905693d 100644
--- a/libavformat/avformat.c
+++ b/libavformat/avformat.c
@@ -679,6 +679,7 @@ AVRational av_guess_sample_aspect_ratio(AVFormatContext
*format, AVStream *strea
AVRational av_guess_frame_rate(AVFormatContext *format, AVStream *st, AVFrame
*frame)
{
AVRational fr = st->r_frame_rate;
+const AVCodecDescriptor *desc = cffstream(st)->codec_desc;
AVCodecContext *const avctx = ffstream(st)->avctx;
AVRational codec_fr = avctx->framerate;
AVRational avg_fr = st->avg_frame_rate;
@@ -688,7 +689,7 @@ AVRational av_guess_frame_rate(AVFormatContext *format,
AVStream *st, AVFrame *f
fr = avg_fr;
}
-if (avctx->ticks_per_frame > 1) {
+if (desc && (desc->props & AV_CODEC_PROP_FIELDS)) {
if ( codec_fr.num > 0 && codec_fr.den > 0 &&
(fr.num == 0 || av_q2d(codec_fr) < av_q2d(fr)*0.7 && fabs(1.0 -
av_q2d(av_div_q(avg_fr, fr))) > 0.1))
fr = codec_fr;
@@ -701,10 +702,12 @@ int avformat_transfer_internal_stream_timing_info(const
AVOutputFormat *ofmt,
AVStream *ost, const
AVStream *ist,
enum AVTimebaseSource
copy_tb)
{
+const AVCodecDescriptor *desc = cffstream(ist)->codec_desc;
const AVCodecContext *const dec_ctx = cffstream(ist)->avctx;
AVCodecContext *const enc_ctx = ffstream(ost)->avctx;
-AVRational dec_ctx_tb = dec_ctx->framerate.num ?
av_inv_q(av_mul_q(dec_ctx->framerate,
-
(AVRational){dec_ctx->ticks_per_frame, 1}))
+
+AVRational mul = (AVRational){ desc && (desc->props &
AV_CODEC_PROP_FIELDS) ? 2 : 1, 1 };
+AVRational dec_ctx_tb = dec_ctx->framerate.num ?
av_inv_q(av_mul_q(dec_ctx->framerate, mul))
:
(ist->codecpar->codec_type == AVMEDIA_TYPE_AUDIO ? (AVRational){0, 1}
: ist->time_base);
[FFmpeg-devel] [PATCH] avcodec/libmp3lame: make it possible to set copyright/original flags
I'd like the control the copyright and original bits in output MP3 frames. I've
added two options to the libmp3lame encoder, the defaults are copying the
defaults from LAME (original=1, copyright=0). Patch attached.
Regards,
Lukas LalinskyFrom 3f5d5f99e862b66867a8a93c8e5928b9e866e010 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Luk=C3=A1=C5=A1=20Lalinsk=C3=BD?=
Date: Tue, 9 May 2023 08:30:03 +0200
Subject: [PATCH] avcodec/libmp3lame: make it possible to set
copyright/original flags
---
doc/encoders.texi | 8
libavcodec/libmp3lame.c | 16 +---
2 files changed, 21 insertions(+), 3 deletions(-)
diff --git a/doc/encoders.texi b/doc/encoders.texi
index 3cb6fc1ce7..f8c691ba1a 100644
--- a/doc/encoders.texi
+++ b/doc/encoders.texi
@@ -864,6 +864,14 @@ Enable the encoder to use ABR when set to 1. The @command{lame}
@option{--abr} sets the target bitrate, while this options only
tells FFmpeg to use ABR still relies on @option{b} to set bitrate.
+@item copyright (@emph{-c})
+Set MPEG audio copyright flag when set to 1. The default value is 0
+(disabled).
+
+@item original (@emph{-o})
+Set MPEG audio original flag when set to 1. The default value is 1
+(enabled).
+
@end table
@section libopencore-amrnb
diff --git a/libavcodec/libmp3lame.c b/libavcodec/libmp3lame.c
index e119189f2a..312bc4230f 100644
--- a/libavcodec/libmp3lame.c
+++ b/libavcodec/libmp3lame.c
@@ -55,6 +55,8 @@ typedef struct LAMEContext {
float *samples_flt[2];
AudioFrameQueue afq;
AVFloatDSPContext *fdsp;
+int copyright;
+int original;
} LAMEContext;
@@ -137,6 +139,12 @@ static av_cold int mp3lame_encode_init(AVCodecContext *avctx)
/* bit reservoir usage */
lame_set_disable_reservoir(s->gfp, !s->reservoir);
+/* copyright flag */
+lame_set_copyright(s->gfp, s->copyright);
+
+/* original flag */
+lame_set_original(s->gfp, s->original);
+
/* set specified parameters */
if (lame_init_params(s->gfp) < 0) {
ret = AVERROR_EXTERNAL;
@@ -303,9 +311,11 @@ static int mp3lame_encode_frame(AVCodecContext *avctx, AVPacket *avpkt,
#define OFFSET(x) offsetof(LAMEContext, x)
#define AE AV_OPT_FLAG_AUDIO_PARAM | AV_OPT_FLAG_ENCODING_PARAM
static const AVOption options[] = {
-{ "reservoir","use bit reservoir", OFFSET(reservoir),AV_OPT_TYPE_BOOL, { .i64 = 1 }, 0, 1, AE },
-{ "joint_stereo", "use joint stereo", OFFSET(joint_stereo), AV_OPT_TYPE_BOOL, { .i64 = 1 }, 0, 1, AE },
-{ "abr", "use ABR", OFFSET(abr), AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0, 1, AE },
+{ "reservoir","use bit reservoir", OFFSET(reservoir),AV_OPT_TYPE_BOOL, { .i64 = 1 }, 0, 1, AE },
+{ "joint_stereo", "use joint stereo", OFFSET(joint_stereo), AV_OPT_TYPE_BOOL, { .i64 = 1 }, 0, 1, AE },
+{ "abr", "use ABR",OFFSET(abr), AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0, 1, AE },
+{ "copyright","set copyright flag", OFFSET(copyright),AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0, 1, AE},
+{ "original", "set original flag", OFFSET(original), AV_OPT_TYPE_BOOL, { .i64 = 1 }, 0, 1, AE},
{ NULL },
};
--
2.25.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/3] avformat/dashdec: fail on probing non mpd file extension
On 09/05/2023 08:19, Anton Khirnov wrote: Quoting Michael Niedermayer (2023-05-09 00:35:08) On Mon, May 08, 2023 at 04:05:40PM +0200, Tobias Rapp wrote: [...] DASH is usually transferred over HTTP where file extensions are of minor interest, the relevant type information is in the Mime-Type header. would anyone be opposed to return 0 from dash_probe() when both the mime_type and the extension are wrong ? I would. probe() is for probing, not implementing security policies. IMO trying to fix security issues at the wrong layer will only lead to more confusion, more complexity, and LESS security. I agree that probing should be unrelated to the actual format selection policy. example: a crafted image.jpeg uploaded somewhere is played as dash. or am i missing something that would stop that ? The player application could exclude the dash format (and other playlist formats) from the format_whitelist I guess? The alternative for the player application if it doesn't need to depend on the system installation of FFmpeg libraries would be to exclude unwanted formats at compilation time. Regards, Tobias ___ 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] libavcodec/webp: add support for animated WebP decoding
Quoting Thilo Borgmann (2023-04-27 20:08:50) > From: Josef Zlomek > > Fixes: 4907 > > Adds support for decoding of animated WebP. > > The WebP parser now splits the input stream into packets containing one frame. > > The WebP decoder adds the animation related features according to the specs: > https://developers.google.com/speed/webp/docs/riff_container#animation > The frames of the animation may be smaller than the image canvas. > Therefore, the frame is decoded to a temporary frame, > then it is blended into the canvas, the canvas is copied to the output frame, > and finally the frame is disposed from the canvas. > > The output to AV_PIX_FMT_YUVA420P/AV_PIX_FMT_YUV420P is still supported. > The background color is specified only as BGRA in the WebP file > so it is converted to YUVA if YUV formats are output. > > Signed-off-by: Josef Zlomek > --- > Changelog| 1 + > libavcodec/codec_desc.c | 3 +- > libavcodec/version.h | 2 +- > libavcodec/webp.c| 713 +++ This patch is unreadable and should be split. -- Anton Khirnov ___ 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/3] avformat/dashdec: fail on probing non mpd file extension
Quoting Michael Niedermayer (2023-05-09 00:35:08)
> On Mon, May 08, 2023 at 04:05:40PM +0200, Tobias Rapp wrote:
> > On 08/05/2023 14:00, James Almer wrote:
> >
> > > On 5/6/2023 10:25 AM, Michael Niedermayer wrote:
> > > > Its unexpected that a .avi or other "standard" file turns into a
> > > > playlist.
> > > > The goal of this patch is to avoid this unexpected behavior and possible
> > > > privacy or security differences.
> > > >
> > > > This is similar to the same change to hls
> > > >
> > > > Signed-off-by: Michael Niedermayer
> > > > ---
> > > > libavformat/dashdec.c | 11 +++
> > > > 1 file changed, 7 insertions(+), 4 deletions(-)
> > > >
> > > > diff --git a/libavformat/dashdec.c b/libavformat/dashdec.c
> > > > index 29d4680c68..294e14150d 100644
> > > > --- a/libavformat/dashdec.c
> > > > +++ b/libavformat/dashdec.c
> > > > @@ -2336,10 +2336,13 @@ static int dash_probe(const AVProbeData *p)
> > > > av_stristr(p->buf, "dash:profile:isoff-live:2011") ||
> > > > av_stristr(p->buf, "dash:profile:isoff-live:2012") ||
> > > > av_stristr(p->buf, "dash:profile:isoff-main:2011") ||
> > > > - av_stristr(p->buf, "3GPP:PSS:profile:DASH1")) {
> > > > - return AVPROBE_SCORE_MAX;
> > > > - }
> > > > - if (av_stristr(p->buf, "dash:profile")) {
> > > > + av_stristr(p->buf, "3GPP:PSS:profile:DASH1") ||
> > > > + av_stristr(p->buf, "dash:profile")) {
> > > > + if (!av_match_ext(p->filename, "mpd")) {
> > > > + av_log(NULL, AV_LOG_ERROR, "Not detecting dash with non
> > > > standard extension\n");
> > > > + return 0;
> > > > + }
> > > > +
> > > > return AVPROBE_SCORE_MAX;
> > > > }
> > >
> > > Failing because it didn't match an extensions sort of goes against the
> > > point of probing, which even has a low score return value that's
> > > basically "it matched extension" as a sort of last resort.
> > >
> > > I'd say wrap this in a FF_COMPLIANCE_STRICT check (since i assume the
> > > spec does state mpd must be the extension), but i think we have no
> > > access to the AVFormatContext here?
> >
> > DASH is usually transferred over HTTP where file extensions are of minor
> > interest, the relevant type information is in the Mime-Type header.
>
> would anyone be opposed to return 0 from dash_probe() when
> both the mime_type and the extension are wrong ?
I would.
probe() is for probing, not implementing security policies. IMO trying
to fix security issues at the wrong layer will only lead to more
confusion, more complexity, and LESS security.
--
Anton Khirnov
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avformat/hls: fail on probing non hls/m3u8 file extensions
Quoting Michael Niedermayer (2023-05-09 01:25:00) > On Sun, May 07, 2023 at 10:42:56PM +0200, Anton Khirnov wrote: > > Quoting Michael Niedermayer (2023-05-03 14:30:38) > > > Its unexpected that a .avi or other "standard" file turns into a playlist. > > > The goal of this patch is to avoid this unexpected behavior and possible > > > privacy or security differences. > > > > > > > I very much dislike this approach. > > What else do you suggest ? > > We could have a configuration option that specifies one > or more trusted directories/files/urls. And everything outside would be > limited to selfcontained files > The average user can put * as trusted url if thats what they want > While someone who cares about their privacy and security could restrict > that with little effort to the place where they store their music and > videos which they know is ok. While OTOH still throwing random URLs > at ffmpeg without expecting overly unexpected results (not considering bugs) > Thats similar to how some office software can handle macros. > > Or do you have some other suggestion ? > I don't see what actual problem is this supposed to address. The commit message mentions some vague "possible issues", but * this seems like the wrong layer for this kind of policy decisions * I think there needs to be a clearly defined thread model before we can discuss what the right solution is -- Anton Khirnov ___ 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".
