Re: [FFmpeg-devel] [PATCH v1] lavfi: add nlmeans CUDA filter

[Dylan Fernando]

On Sat, Aug 14, 2021 at 9:11 AM Timo Rothenpieler 
wrote:

> On 13.08.2021 10:42, Dylan Fernando wrote:
> > Any update on this?
> >
> > Kind Regards,
> > Dylan
>
> Also, are you sure that exp() function is correct?
>
> The CUDA-Function exp() is defined as "double exp(double x)" and
> calculates the base e exponential.
>
> While __nvvm_ex2_approx_f reads to me like it does so for floats, and
> for base 2. For which the CUDA equivalent would be "float exp2f(float)".
>
> ___
> 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".
>

I wasn't sure about the exp() function. Is there a function like
__nvvm_exp_approx_d? I can't seem to find a function for this.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [RFC] Suggestion for a Nicer Integration with GitHub

[zhilizhao(赵志立)]

> On Aug 14, 2021, at 11:27 AM, ffmpegandmahanstreamer@e.email wrote:
> 
> August 13, 2021 8:42 PM, "Ronald S. Bultje"  wrote:
> 
>> Hi,
>> 
>> On Thu, Aug 12, 2021 at 4:51 AM Nicolas George  wrote:
>> 
>>> Paul Buxton (12021-08-12):
>>> From the point of view of someone who is currently developing a filter
>>> for
>>> ffmpeg and will be submitting a patch to the list for the first time, I
>>> think this is a great idea.Whilst following simple instructions to
>>> prepare
>>> and submit a patch should't be outside the ability of anyone who is
>>> capable
>>> of contributing. Using something like github allows a more automated
>>> workflow that can make the process smoother and even make lives easier
>>> for
>>> the maintainers as it is possible for the automations to catch issues
>>> before they get sent on to you.
>>> 
>>> Have you wondered why these periodical threads "we/you should make
>>> FFmpeg more attractive" usually end up a discussion between disgruntled
>>> newbies congratulating each other for their great ideas, with only the
>>> occasional bored experienced developer stepping in?
>> 
>> Experienced dev speaking here: I absolutely 100% disagree with this
>> statement. I would be much happier to actively contribute to FFmpeg if it
>> used gitlab/hub. I find this mailinglist environment beyond horrendous. I
>> can't understand why anyone would be OK with our current approach. I only
>> grudgingly use it when I need to because I'm assuming I'm the minority and
>> I'm willing to accept the majority consensus, but not because I support it
>> or think it's a good idea.
> 
> This reminds me: dav1d, gstreamer, nihav, VLC, x265, rav1e, svt-vp9, etc. and 
> other major
> multimedia projects are now all on Github/Gitlab/some graphical platform. 
> Its' ffmpeg that's mostly
> stuck in the past. Everyone's moving on. To be fair, all the projects (except 
> gstreamer and vlc)
> started off that way, but it shows where the general trend it still.

I’m glad VLC development has transfer from mailing list to self hosted Gitlab, 
although it’s not
perfect, e.g., gitlab is slow for large patch set.

I have spent a lot of time on finding a email service provider for mailing list 
based development:

- All patches are treated as spam by 163.com, I can't sent a single email 
(well, patch doesn’t look
like normal conversation…)
- Email backend developer or client developer don’t know about the use case of 
mailing list, they
don’t understand my bug report, or don’t care.
- gmail is blocked by GFW, that’s another story…

I’ve helped my friends to setup email for sending patch. It’s like DIY shoes 
before jogging. DIY is
interesting, but definitely time consuming. Coding is a necessary skill for 
contributing, debugging
is a necessary skill for contributing, but vim is not, no matter how I like it.

Maybe there are some details which are overlooked on the GitGitGadget solution, 
but “easy to
contributing and more contributor will lower the patch quality” is not a good 
reason to reject the
solution.

> 
> Its not just multimedia, major projects from all over the OSS sphere are 
> moving to these graphical
> platforms. Even webkit and clang, some of the largest codebases.
> 
> If people loved mailing lists all those projects would start off with those 
> and still use them.
> 
> Again, why use a slide rule when there are calculators?
> 
> Again, there are many platforms that are not full blown github/gitlab like 
> gitea, codeberg, gogs,
> gitbucket etc. that are very nice.
> 
> To be honest, i do think the mailing list should be eventually phased out. 
> And i think it will be,
> as fresh blood comes in from younger kids who have been using the graphical 
> platforms for their
> entire programming career. It may happen next month, it may happen in one 
> year, it may happen in 5
> years. But it will happen.
> 
>> Ronald
>> ___
>> ffmpeg-devel mailing list
>> ffmpeg-devel@ffmpeg.org
>> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>> 
>> To unsubscribe, visit link above, or email
>> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
> 

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] avcodec/libaomenc: use ctx->usage to get default cfg

[James Zern]

On Fri, Aug 13, 2021 at 7:11 PM James Zern  wrote:
>
> this prevents some mismatches in config values for realtime and all
> intra modes, avoiding failures like:
>

The logic for default crf may need some work with -usage 2.

> [libaom-av1 @ ...] Failed to initialize encoder: Invalid parameter
> [libaom-av1 @ ...]   Additional information: g_lag_in_frames out of
> range [..0]
> ---
>  libavcodec/libaomenc.c | 4 +---
>  1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/libavcodec/libaomenc.c b/libavcodec/libaomenc.c
> index 9c0317f3b2..800fda0591 100644
> --- a/libavcodec/libaomenc.c
> +++ b/libavcodec/libaomenc.c
> @@ -599,7 +599,7 @@ static av_cold int aom_init(AVCodecContext *avctx,
>  av_log(avctx, AV_LOG_INFO, "%s\n", aom_codec_version_str());
>  av_log(avctx, AV_LOG_VERBOSE, "%s\n", aom_codec_build_config());
>
> -if ((res = aom_codec_enc_config_default(iface, , 0)) != 
> AOM_CODEC_OK) {
> +if ((res = aom_codec_enc_config_default(iface, , ctx->usage)) != 
> AOM_CODEC_OK) {
>  av_log(avctx, AV_LOG_ERROR, "Failed to get config: %s\n",
> aom_codec_err_to_string(res));
>  return AVERROR(EINVAL);
> @@ -623,8 +623,6 @@ static av_cold int aom_init(AVCodecContext *avctx,
>  enccfg.g_threads  =
>  FFMIN(avctx->thread_count ? avctx->thread_count : av_cpu_count(), 
> 64);
>
> -enccfg.g_usage= ctx->usage;
> -
>  if (ctx->lag_in_frames >= 0)
>  enccfg.g_lag_in_frames = ctx->lag_in_frames;
>
> --
> 2.33.0.rc1.237.g0d66db33f3-goog
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH] avcodec/libaomenc: use ctx->usage to get default cfg

[James Zern]

this prevents some mismatches in config values for realtime and all
intra modes, avoiding failures like:

[libaom-av1 @ ...] Failed to initialize encoder: Invalid parameter
[libaom-av1 @ ...]   Additional information: g_lag_in_frames out of
range [..0]
---
 libavcodec/libaomenc.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/libavcodec/libaomenc.c b/libavcodec/libaomenc.c
index 9c0317f3b2..800fda0591 100644
--- a/libavcodec/libaomenc.c
+++ b/libavcodec/libaomenc.c
@@ -599,7 +599,7 @@ static av_cold int aom_init(AVCodecContext *avctx,
 av_log(avctx, AV_LOG_INFO, "%s\n", aom_codec_version_str());
 av_log(avctx, AV_LOG_VERBOSE, "%s\n", aom_codec_build_config());
 
-if ((res = aom_codec_enc_config_default(iface, , 0)) != 
AOM_CODEC_OK) {
+if ((res = aom_codec_enc_config_default(iface, , ctx->usage)) != 
AOM_CODEC_OK) {
 av_log(avctx, AV_LOG_ERROR, "Failed to get config: %s\n",
aom_codec_err_to_string(res));
 return AVERROR(EINVAL);
@@ -623,8 +623,6 @@ static av_cold int aom_init(AVCodecContext *avctx,
 enccfg.g_threads  =
 FFMIN(avctx->thread_count ? avctx->thread_count : av_cpu_count(), 64);
 
-enccfg.g_usage= ctx->usage;
-
 if (ctx->lag_in_frames >= 0)
 enccfg.g_lag_in_frames = ctx->lag_in_frames;
 
-- 
2.33.0.rc1.237.g0d66db33f3-goog

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [RFC] Suggestion for a Nicer Integration with GitHub

[Soft Works]

> -Original Message-
> From: ffmpeg-devel  On Behalf Of Lynne
> Sent: Saturday, 14 August 2021 03:08
> To: FFmpeg development discussions and patches 
> Subject: Re: [FFmpeg-devel] [RFC] Suggestion for a Nicer Integration with
> GitHub
> 

> The situation is far from perfect. In my opinion, mirroring will just
> result in such an incredible amount of noise on the ML, the ML
> will turn useless anyway, and due to needing to maintain both,
> one will fall out of favour with developers and will break, while
> limiting the integration for the other.

I'm don't think it would create much noise, please see my reply to
Michael from 1.5h ago.

There's no need to maintain both, because what happens on GitHub is 
automated and the ML remains the core instrument.

Should it turn out over time that activity would converge away
from the ML, then this would be a natural and democratic evolvement.
Then, it would be time to reconsider the organization, obviously.

> I'd rather move to either a self-hosted Gitea or Gogs instance,
> or failing that, Github. IMO Gitea is pretty good and fast. As bad
> as that could be, it'll be better than what we have now or could have
> with Gitlab.

These kinds of proposals have been talked down too often, that's 
why I'm suggesting something with a more realistic chance for acceptance
and that won't hurt or affect anybody in his work if he doesn't want.

Also, the stakes are much lower than with a full migration.
If it wouldn't work out well, it can be abandoned easily, while a 
migration is usually a way of no return.


softworkz 


___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [RFC] Suggestion for a Nicer Integration with GitHub

[Soft Works]

> -Original Message-
> From: ffmpeg-devel  On Behalf Of Ronald S.
> Bultje
> Sent: Saturday, 14 August 2021 02:43
> To: FFmpeg development discussions and patches 
> Subject: Re: [FFmpeg-devel] [RFC] Suggestion for a Nicer Integration with
> GitHub
> 
> Hi,
> 
> On Thu, Aug 12, 2021 at 4:51 AM Nicolas George  wrote:
> 
> > Paul Buxton (12021-08-12):
> > > From the point of view of someone who is currently developing a filter
> > for
> > > ffmpeg and will be submitting a patch to the list for the first time, I
> > > think this is a great idea.Whilst following simple instructions to
> > prepare
> > > and submit a patch should't be outside the ability of anyone who is
> > capable
> > > of contributing. Using something like github allows a more automated
> > > workflow that can make the process smoother and even make lives easier
> > for
> > > the maintainers as it is possible for the automations to catch issues
> > > before they get sent on to you.
> >
> > Have you wondered why these periodical threads "we/you should make
> > FFmpeg more attractive" usually end up a discussion between disgruntled
> > newbies congratulating each other for their great ideas, with only the
> > occasional bored experienced developer stepping in?
> >
> 
> Experienced dev speaking here: I absolutely 100% disagree with this
> statement. I would be much happier to actively contribute to FFmpeg if it
> used gitlab/hub. I find this mailinglist environment beyond horrendous. I
> can't understand why anyone would be OK with our current approach. I only
> grudgingly use it when I need to because I'm assuming I'm the minority and
> I'm willing to accept the majority consensus, but not because I support it
> or think it's a good idea.

The continuing attempt to declare developers who are favoring modern 
workflows and tooling as newbies and unexperienced is a really disgusting
rhetoric.
I'm glad that you haven't become a victim of that rhetoric. I'm sure that 
there's one or the other who prefer to keep quiet for that reason..

softworkz  
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [RFC] Suggestion for a Nicer Integration with GitHub

[Lynne]

Aug 14, 2021, 02:42 by rsbul...@gmail.com:

> Hi,
>
> On Thu, Aug 12, 2021 at 4:51 AM Nicolas George  wrote:
>
>> Paul Buxton (12021-08-12):
>> > From the point of view of someone who is currently developing a filter
>> for
>> > ffmpeg and will be submitting a patch to the list for the first time, I
>> > think this is a great idea.Whilst following simple instructions to
>> prepare
>> > and submit a patch should't be outside the ability of anyone who is
>> capable
>> > of contributing. Using something like github allows a more automated
>> > workflow that can make the process smoother and even make lives easier
>> for
>> > the maintainers as it is possible for the automations to catch issues
>> > before they get sent on to you.
>>
>> Have you wondered why these periodical threads "we/you should make
>> FFmpeg more attractive" usually end up a discussion between disgruntled
>> newbies congratulating each other for their great ideas, with only the
>> occasional bored experienced developer stepping in?
>>
>
> Experienced dev speaking here: I absolutely 100% disagree with this
> statement. I would be much happier to actively contribute to FFmpeg if it
> used gitlab/hub. I find this mailinglist environment beyond horrendous. I
> can't understand why anyone would be OK with our current approach. I only
> grudgingly use it when I need to because I'm assuming I'm the minority and
> I'm willing to accept the majority consensus, but not because I support it
> or think it's a good idea.
>

You're not the minority. The last week we've had such unorganized
patchdumps, it's impossible to read all of them. A lot of patches go
rotting because they haven't received enough attention, and patchwork
doesn't integrate perfectly to highlight them.
We've discussed this somewhat on IRC, and there, pretty much everyone
received the idea to move well. But out here on the ML (not exactly a
neutral ground, discussing its replacement on itself), it's a different
story.

Hosting your own mail address is pretty futile nowadays. It'll be useless
for anything but the ML, unless you take it seriously, admin it properly,
make sure your IP address has a clean history, keep up with DKIM,
DMARC, and other new extensions which unless you implement, you
can't be sure your messages won't go to spam, or outright deleted.
Moreover, even if you pay for someone else to do it for you, it's not
cheap, it's usually garbage (I know mine is, that's why I have to attach
patches instead of use git send-email), and due to the sheer amount
of noise, it's hard to keep up with what needs attention other than
read *everything* to not miss something.

Gitlab plain sucks. It's a very buggy, crappy piece of non-free/freemium
software, made by a company that fully sold out to investors, turned
downright evil and fully embraced the enterprise. It takes hours to open
patch diffs for small patchsets, it frequently just plainly errors out
client-side, it requires constat daily administration to remove spam
accounts, and some projects just plainly close registrations and ask that
you ask on IRC to get an account so you can file bugs/send patches.

The situation is far from perfect. In my opinion, mirroring will just
result in such an incredible amount of noise on the ML, the ML
will turn useless anyway, and due to needing to maintain both,
one will fall out of favour with developers and will break, while
limiting the integration for the other.

I'd rather move to either a self-hosted Gitea or Gogs instance,
or failing that, Github. IMO Gitea is pretty good and fast. As bad
as that could be, it'll be better than what we have now or could have
with Gitlab.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [RFC] Suggestion for a Nicer Integration with GitHub

[Ronald S. Bultje]

Hi,

On Thu, Aug 12, 2021 at 4:51 AM Nicolas George  wrote:

> Paul Buxton (12021-08-12):
> > From the point of view of someone who is currently developing a filter
> for
> > ffmpeg and will be submitting a patch to the list for the first time, I
> > think this is a great idea.Whilst following simple instructions to
> prepare
> > and submit a patch should't be outside the ability of anyone who is
> capable
> > of contributing. Using something like github allows a more automated
> > workflow that can make the process smoother and even make lives easier
> for
> > the maintainers as it is possible for the automations to catch issues
> > before they get sent on to you.
>
> Have you wondered why these periodical threads "we/you should make
> FFmpeg more attractive" usually end up a discussion between disgruntled
> newbies congratulating each other for their great ideas, with only the
> occasional bored experienced developer stepping in?
>

Experienced dev speaking here: I absolutely 100% disagree with this
statement. I would be much happier to actively contribute to FFmpeg if it
used gitlab/hub. I find this mailinglist environment beyond horrendous. I
can't understand why anyone would be OK with our current approach. I only
grudgingly use it when I need to because I'm assuming I'm the minority and
I'm willing to accept the majority consensus, but not because I support it
or think it's a good idea.

Ronald
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [RFC] Suggestion for a Nicer Integration with GitHub

[Soft Works]

> -Original Message-
> From: ffmpeg-devel  On Behalf Of
> Michael Niedermayer
> Sent: Friday, 13 August 2021 20:10
> To: FFmpeg development discussions and patches  de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [RFC] Suggestion for a Nicer Integration
> with GitHub
> 
> On Fri, Aug 13, 2021 at 03:14:36PM +, Soft Works wrote:
> [...]
> > > You do not need anybody's permission either to set up a gateway
> that
> > > will re-post GitHub's PR and comments to the mailing-list and
> > > reciprocally
> >
> > I would need permission to github/ffmpeg/ffmpeg in order to set
> > up the automation hooks.
> 
> what exactly is needed to be done, what exact permission is needed
> are we talking about adding a link  /API key somewhere or
> continues maintaince of some parameters which require specific
> permissions?

This is implemented via typescript functions running on Azure, 
so it will be rather a one time setup, at the side of the GitHub
repository and maintenance can be done at the Azure site.

BTW, do you own https://dev.azure.com/ffmpeg or has somebody else
registered that one?

I could register something like ffmpeg_sync or ffmpeg_ggg otherwise
and transfer ownership to the project later (or upfront).

> > Also I wouldn't do it as long as there is at least some kind
> > of "let's try it out as an experiment" feedback from here.
> 
> I think ultimately none of us knows how it would look/behave before
> its done. So its hard to avoid that it would be an experiment

Surely true.

But even when it wouldn’t work well in terms of submitting - the
other direction alone would be a great value IMO: being able to 
view patches submitted to the ML mirrored as GitHub PRs.
This allows viewing patches in context of the latest master-HEAD
without needing to fetch latest, download patch and apply patch
locally.


> I do not know "GGG", but what happens once a PR is submitted to the
> ML?
> People will write replies on the ML to comment, ask for changes and
> so forth.
> Simlarly on github PRs can receive comments, reviews, approvals and
> so on
> is there some routing of such comments between PR and ML ?

Yes there is, but currently only from mailing list back as a PR comment
PR comments are not yet sent to the ML. Need to find out the reason
why the aren't doing it or add this functionality. 
Essentially, developers are still required to reply on the mailing list.

But what's nice is that developers can make the requested changes
to their PR source branch, /submit again and GGG will automatically
submit this as v2..vN patchset.

I think it's best to look an example: 

https://github.com/gitgitgadget/git/pull/1006 

> another thing needed, if we would allow PRs is that automated fate
> testing
> of such PRs should be implemented. Thats a great way to filter out
> bad PRs beyond just a author list

Yes absolutely. This can be done just normally as GitHub checks/actions:

- Conformance of submit message
- Compilation (ideally multiple platforms)
- FATE
- Possibly some code style checking
(for GIT, they have set up 46 checks currently)

They don't make successful completion of all checks a requirement, 
but that's something I would possibly change.


What I'm still thinking about is the part about hooking into ML 
e-mail reception. They are using https://public-inbox.org/
for GIT, but it would need to be hosted somewhere.
Either I'll figure out a different way or I'll self-host it for an
initial phase.

Regards,
softworkz
 

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] libavcodec/libx264: add user data unregistered SEI encoding

[Brad Hards]

On Friday, 6 August 2021 7:16:33 PM AEST Brad Hards wrote:
> MISB ST 0604 and ST 2101 require user data unregistered SEI messages
> (precision timestamps and sensor identifiers) to be included. That
> currently isn't supported for libx264. This patch adds support
> for user data unregistered SEI messages in accordance with ISO/IEC
> 14496-10:2020(E) section D.1.7 (syntax) and D.2.7 (semantics).
> 
> This code is based on a similar change for libx265 (commit
> 1f58503013720700a5adfd72c708e6275aefc165).
> ---
>  libavcodec/libx264.c | 30 ++
>  1 file changed, 30 insertions(+)
> 
> diff --git a/libavcodec/libx264.c b/libavcodec/libx264.c
> index 9afaf19547..e9bbe8d494 100644
> --- a/libavcodec/libx264.c
> +++ b/libavcodec/libx264.c
> @@ -32,6 +32,7 @@
>  #include "internal.h"
>  #include "packet_internal.h"
>  #include "atsc_a53.h"
> +#include "sei.h"
>  
>  #if defined(_MSC_VER)
>  #define X264_API_IMPORTS 1
> @@ -114,6 +115,9 @@ typedef struct X264Context {
>   * encounter a frame with ROI side data.
>   */
>  int roi_warned;
> +
> +void *sei_data;
> +int sei_data_size;
>  } X264Context;
>  
>  static void X264_log(void *p, int level, const char *fmt, va_list args)
> @@ -317,6 +321,9 @@ static int X264_frame(AVCodecContext *ctx, AVPacket *pkt, 
> const AVFrame *frame,
>  x4->pic.img.i_plane = avfmt2_num_planes(ctx->pix_fmt);
>  
>  if (frame) {
> +x264_sei_t *sei = >pic.extra_sei;
> +sei->num_payloads = 0;
> +
>  for (i = 0; i < x4->pic.img.i_plane; i++) {
>  x4->pic.img.plane[i]= frame->data[i];
>  x4->pic.img.i_stride[i] = frame->linesize[i];
> @@ -439,6 +446,27 @@ static int X264_frame(AVCodecContext *ctx, AVPacket 
> *pkt, const AVFrame *frame,
>  }
>  }
>  }
> +
> +for (int j = 0; j < frame->nb_side_data; j++) {
> +AVFrameSideData *side_data = frame->side_data[j];
> +void *tmp;
> +x264_sei_payload_t *sei_payload;
> +if (side_data->type != AV_FRAME_DATA_SEI_UNREGISTERED)
> +continue;
> +tmp = av_fast_realloc(x4->sei_data, >sei_data_size, 
> (sei->num_payloads + 1) * sizeof(*sei_payload));
> +if (!tmp) {
> +av_freep(>pic.extra_sei.payloads);
> +av_freep(>pic.prop.quant_offsets);
> +return AVERROR(ENOMEM);
> +}
> +x4->sei_data = tmp;
> +sei->payloads = x4->sei_data;
> +sei_payload = >payloads[sei->num_payloads];
> +sei_payload->payload = side_data->data;
> +sei_payload->payload_size = side_data->size;
> +sei_payload->payload_type = SEI_TYPE_USER_DATA_UNREGISTERED;
> +sei->num_payloads++;
> +}
>  }
>  
>  do {
> @@ -505,6 +533,8 @@ static av_cold int X264_close(AVCodecContext *avctx)
>  x264_param_cleanup(>params);
>  #endif
>  
> +av_freep(>sei_data);
> +
>  if (x4->enc) {
>  x264_encoder_close(x4->enc);
>  x4->enc = NULL;
> 
Ping on this patch.

Brad



___
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 v1] lavfi: add nlmeans CUDA filter

[Timo Rothenpieler]

On 13.08.2021 10:42, Dylan Fernando wrote:

Any update on this?

Kind Regards,
Dylan


Also, are you sure that exp() function is correct?

The CUDA-Function exp() is defined as "double exp(double x)" and 
calculates the base e exponential.


While __nvvm_ex2_approx_f reads to me like it does so for floats, and 
for base 2. For which the CUDA equivalent would be "float exp2f(float)".




smime.p7s
Description: S/MIME Cryptographic 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 v1] lavfi: add nlmeans CUDA filter

[Timo Rothenpieler]

On 13.08.2021 10:42, Dylan Fernando wrote:

Any update on this?


Missing license header in both new files (please re-send for this).
Missing version bump, though I can add this when pushing as well.

The code looks fine to me, though I have no experience with this 
algorithm at all, so if someone who does could give it a look, that'd be 
greatly appreciated.




smime.p7s
Description: S/MIME Cryptographic 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] Consulting request video pre-processing for media project involving machine learning

[ffmpegandmahanstreamer]

August 13, 2021 11:10 AM, "Mario Winkler"  wrote:

> Dear Developers
> 
> I direct a media project involving a huge variety of online available videos. 
> We will analyse these
> videos with available and state of the art machine learning tools, but need 
> to pre-process the
> videos and bring them to a certain standard.
> 
More detail needed, whats end goal?
> We are looking for somebody to consult to automated pre-process the videos.
> 
> The videos we have collected by now:
> 3 videos downloaded from different sources (YouTube, IG, Tiktok) and with 
> a huge variety in
> quality, length, size, bitrate and format. 300GB total size.
> 
Are they of a specific type or 3 completely different videos?
> Goal of the preprocessing (TBD):
> - remove black bars
Black vertical or horizontal bars? Need more info. Should be a filter that can 
handle this already though.

> - remove items added to the video by 3rd parties (like ’this is my YouTube 
> channel’ before the
> actual video starts) etc.
Delogo filter might help you here.

But if its determining like the sponsorship things and the intros thats way way 
out of scope of ffmpeg. 

> - similar framerate
> - similar codec
> - similar bitrate
> 
If this is for what I think its for, none of this stuff will help you. All 
codecs are "different" but ffmpeg can help you determine which codec a video 
is, along with framerate and bitrate.

> I just learned from your software, but feel like you might be the right fit 
> to help us with this.
> If you are interested, please contact me and I will setup a call.
> 
It certainly is intresting, please let me know where the project goes. Most of 
the stuff may be filter related, but for the most part it looks like its out of 
scope. Good luck.

> Best,
> Mario
> ___
> Mario Winkler Company LLC is specialised for Project Management of 
> International Contemporary Art
> Projects. We are closing the gaps and and sometimes buffer to make any artist 
> visions reality. 
> 
> Mario Winkler Company GmbH
> Bernerstrasse Nord 180 CH-8064 Zürich
> office +41 55 552 03 00 / m...@mariowinkler.ch
> direct +41 76 566 36 27 / ma...@mariowinkler.ch
> Instagram 
> 

> This email and any attachments to it may be confidential and are
> intended solely for the use of the individual to whom it is addressed.
> If you are not the intended recipient of this email, you must neither
> take any action based upon its contents, nor copy or show it to anyone.
> Please contact the sender if you have received this email in error

Put these things off when posting on public mailing list. Sometimes Nicolas 
does have a point with his ramblings.
> 
> ___
> 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 1/2] imgutils: expose av_image_copy_plane_uc_from()

[Lynne]

Aug 13, 2021, 19:47 by d...@lynne.ee:

> Aug 10, 2021, 17:50 by d...@lynne.ee:
>
>> 10 Aug 2021, 17:29 by andreas.rheinha...@outlook.com:
>>
>>> Lynne:
>>>
 diff --git a/libavutil/version.h b/libavutil/version.h

 index 6b4a265457..678cb9bfa6 100644

 --- a/libavutil/version.h

 +++ b/libavutil/version.h

 @@ -80,7 +80,7 @@



 #define LIBAVUTIL_VERSION_MAJOR  57

 #define LIBAVUTIL_VERSION_MINOR   3

 -#define LIBAVUTIL_VERSION_MICRO 100

 +#define LIBAVUTIL_VERSION_MICRO 101



 #define LIBAVUTIL_VERSION_INT   AV_VERSION_INT(LIBAVUTIL_VERSION_MAJOR, \

 LIBAVUTIL_VERSION_MINOR, \

>>>
>>> An new function always needs a minor bump.
>>>
>>> - Andreas
>>>
>>
>> Thanks, changed locally to a minor bump instead.
>>
>
> Will push this later tonight.
>

Thanks, pushed.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] avcodec/frame_thread_encoder: Free AVCodecContext structure on error during init

[Andreas Rheinhardt]

Michael Niedermayer:
> On Fri, Aug 13, 2021 at 08:34:13PM +0200, Andreas Rheinhardt wrote:
>> Michael Niedermayer:
>>> Fixes: MemLeak
>>> Fixes: 8281
>>> Fixes: PoC_option158.jpg
>>> Fixes: CVE-2020-22037
>>>
>>> Signed-off-by: Michael Niedermayer 
>>> ---
>>>  libavcodec/frame_thread_encoder.c | 10 ++
>>>  1 file changed, 6 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/libavcodec/frame_thread_encoder.c 
>>> b/libavcodec/frame_thread_encoder.c
>>> index 9cabfc495f..25a308173d 100644
>>> --- a/libavcodec/frame_thread_encoder.c
>>> +++ b/libavcodec/frame_thread_encoder.c
>>> @@ -126,7 +126,7 @@ int ff_frame_thread_encoder_init(AVCodecContext *avctx)
>>>  {
>>>  int i=0;
>>>  ThreadContext *c;
>>> -
>>> +AVCodecContext *thread_avctx = NULL;
>>>  
>>>  if(   !(avctx->thread_type & FF_THREAD_FRAME)
>>> || !(avctx->codec->capabilities & AV_CODEC_CAP_FRAME_THREADS))
>>> @@ -202,16 +202,16 @@ int ff_frame_thread_encoder_init(AVCodecContext 
>>> *avctx)
>>>  for(i=0; ithread_count ; i++){
>>>  int ret;
>>>  void *tmpv;
>>> -AVCodecContext *thread_avctx = 
>>> avcodec_alloc_context3(avctx->codec);
>>> +thread_avctx = avcodec_alloc_context3(avctx->codec);
>>>  if(!thread_avctx)
>>>  goto fail;
>>>  tmpv = thread_avctx->priv_data;
>>>  *thread_avctx = *avctx;
>>> +thread_avctx->priv_data = tmpv;
>>> +thread_avctx->internal = NULL;
>>>  ret = av_opt_copy(thread_avctx, avctx);
>>>  if (ret < 0)
>>>  goto fail;
>>> -thread_avctx->priv_data = tmpv;
>>> -thread_avctx->internal = NULL;
>>>  if (avctx->codec->priv_class) {
>>>  int ret = av_opt_copy(thread_avctx->priv_data, 
>>> avctx->priv_data);
>>>  if (ret < 0)
>>> @@ -233,6 +233,8 @@ int ff_frame_thread_encoder_init(AVCodecContext *avctx)
>>>  
>>>  return 0;
>>>  fail:
>>> +avcodec_close(thread_avctx);
>>> +av_freep(_avctx);
>>>  avctx->thread_count = i;
>>>  av_log(avctx, AV_LOG_ERROR, "ff_frame_thread_encoder_init failed\n");
>>>  ff_frame_thread_encoder_free(avctx);
>>>
>> This has some presumptions: First, it relies on undocumented behaviour
>> from av_opt_copy(), see here:
>> https://ffmpeg.org/pipermail/ffmpeg-devel/2021-August/283645.html
> 
> Its documented after your patch ;)
> 
> 
>> Second, you presume that hw_frames_ctx is not set, although it is a
>> valid field for an encoder (although no hardware encoder seems to have
>> the frame threading flag set). If it were set, it would be freed
>> multiple times. (The same goes for several other fields that are not
>> supposed to be set by encoders, but IMO that would be a user problem.)
> 
> What do you suggest, should i add an av_assert on hw_frames_ctx==NULL ?
> 
> 
>> Notice that the second issue exists even when initializing succeeds.
> 
> then its unrelated to the patch, of course we still need to fix it.
> 
> More specifically, should i change the patch ?
> the hw_frames_ctx seems a bug but unrelated, the undocumentedness is
> fixed by you.
> the code feels fragile and not particularly robust before this already
> and fixing this adding nicer and robust API for all steps cant be backported
> and i need to backport the fix so we need a fix without new API
> 
I'd just set hw_frames_ctx to NULL at the same place where you set
internal to NULL; and add a comment about this that frame threaded
hardware encoders are just not supported atm.

- Andreas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] avcodec/frame_thread_encoder: Free AVCodecContext structure on error during init

[James Almer]

On 8/13/2021 3:51 PM, Michael Niedermayer wrote:

On Fri, Aug 13, 2021 at 08:34:13PM +0200, Andreas Rheinhardt wrote:

Michael Niedermayer:

Fixes: MemLeak
Fixes: 8281
Fixes: PoC_option158.jpg
Fixes: CVE-2020-22037

Signed-off-by: Michael Niedermayer 
---
  libavcodec/frame_thread_encoder.c | 10 ++
  1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/libavcodec/frame_thread_encoder.c 
b/libavcodec/frame_thread_encoder.c
index 9cabfc495f..25a308173d 100644
--- a/libavcodec/frame_thread_encoder.c
+++ b/libavcodec/frame_thread_encoder.c
@@ -126,7 +126,7 @@ int ff_frame_thread_encoder_init(AVCodecContext *avctx)
  {
  int i=0;
  ThreadContext *c;
-
+AVCodecContext *thread_avctx = NULL;
  
  if(   !(avctx->thread_type & FF_THREAD_FRAME)

 || !(avctx->codec->capabilities & AV_CODEC_CAP_FRAME_THREADS))
@@ -202,16 +202,16 @@ int ff_frame_thread_encoder_init(AVCodecContext *avctx)
  for(i=0; ithread_count ; i++){
  int ret;
  void *tmpv;
-AVCodecContext *thread_avctx = avcodec_alloc_context3(avctx->codec);
+thread_avctx = avcodec_alloc_context3(avctx->codec);
  if(!thread_avctx)
  goto fail;
  tmpv = thread_avctx->priv_data;
  *thread_avctx = *avctx;
+thread_avctx->priv_data = tmpv;
+thread_avctx->internal = NULL;
  ret = av_opt_copy(thread_avctx, avctx);
  if (ret < 0)
  goto fail;
-thread_avctx->priv_data = tmpv;
-thread_avctx->internal = NULL;
  if (avctx->codec->priv_class) {
  int ret = av_opt_copy(thread_avctx->priv_data, avctx->priv_data);
  if (ret < 0)
@@ -233,6 +233,8 @@ int ff_frame_thread_encoder_init(AVCodecContext *avctx)
  
  return 0;

  fail:
+avcodec_close(thread_avctx);
+av_freep(_avctx);
  avctx->thread_count = i;
  av_log(avctx, AV_LOG_ERROR, "ff_frame_thread_encoder_init failed\n");
  ff_frame_thread_encoder_free(avctx);


This has some presumptions: First, it relies on undocumented behaviour
from av_opt_copy(), see here:
https://ffmpeg.org/pipermail/ffmpeg-devel/2021-August/283645.html


Its documented after your patch ;)



Second, you presume that hw_frames_ctx is not set, although it is a
valid field for an encoder (although no hardware encoder seems to have
the frame threading flag set). If it were set, it would be freed
multiple times. (The same goes for several other fields that are not
supposed to be set by encoders, but IMO that would be a user problem.)


What do you suggest, should i add an av_assert on hw_frames_ctx==NULL ?


We should not av_assert on user set arguments like this. Since no 
encoder uses frame threading, and none will, a simple check and EINVAL, 
or simply setting hw_frames_ctx to NULL on the copied contexts (same as 
with internal), should be enough.






Notice that the second issue exists even when initializing succeeds.


then its unrelated to the patch, of course we still need to fix it.

More specifically, should i change the patch ?
the hw_frames_ctx seems a bug but unrelated, the undocumentedness is
fixed by you.
the code feels fragile and not particularly robust before this already
and fixing this adding nicer and robust API for all steps cant be backported
and i need to backport the fix so we need a fix without new API

thx

[...]


___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".



___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] avcodec/frame_thread_encoder: Free AVCodecContext structure on error during init

[Michael Niedermayer]

On Fri, Aug 13, 2021 at 08:34:13PM +0200, Andreas Rheinhardt wrote:
> Michael Niedermayer:
> > Fixes: MemLeak
> > Fixes: 8281
> > Fixes: PoC_option158.jpg
> > Fixes: CVE-2020-22037
> > 
> > Signed-off-by: Michael Niedermayer 
> > ---
> >  libavcodec/frame_thread_encoder.c | 10 ++
> >  1 file changed, 6 insertions(+), 4 deletions(-)
> > 
> > diff --git a/libavcodec/frame_thread_encoder.c 
> > b/libavcodec/frame_thread_encoder.c
> > index 9cabfc495f..25a308173d 100644
> > --- a/libavcodec/frame_thread_encoder.c
> > +++ b/libavcodec/frame_thread_encoder.c
> > @@ -126,7 +126,7 @@ int ff_frame_thread_encoder_init(AVCodecContext *avctx)
> >  {
> >  int i=0;
> >  ThreadContext *c;
> > -
> > +AVCodecContext *thread_avctx = NULL;
> >  
> >  if(   !(avctx->thread_type & FF_THREAD_FRAME)
> > || !(avctx->codec->capabilities & AV_CODEC_CAP_FRAME_THREADS))
> > @@ -202,16 +202,16 @@ int ff_frame_thread_encoder_init(AVCodecContext 
> > *avctx)
> >  for(i=0; ithread_count ; i++){
> >  int ret;
> >  void *tmpv;
> > -AVCodecContext *thread_avctx = 
> > avcodec_alloc_context3(avctx->codec);
> > +thread_avctx = avcodec_alloc_context3(avctx->codec);
> >  if(!thread_avctx)
> >  goto fail;
> >  tmpv = thread_avctx->priv_data;
> >  *thread_avctx = *avctx;
> > +thread_avctx->priv_data = tmpv;
> > +thread_avctx->internal = NULL;
> >  ret = av_opt_copy(thread_avctx, avctx);
> >  if (ret < 0)
> >  goto fail;
> > -thread_avctx->priv_data = tmpv;
> > -thread_avctx->internal = NULL;
> >  if (avctx->codec->priv_class) {
> >  int ret = av_opt_copy(thread_avctx->priv_data, 
> > avctx->priv_data);
> >  if (ret < 0)
> > @@ -233,6 +233,8 @@ int ff_frame_thread_encoder_init(AVCodecContext *avctx)
> >  
> >  return 0;
> >  fail:
> > +avcodec_close(thread_avctx);
> > +av_freep(_avctx);
> >  avctx->thread_count = i;
> >  av_log(avctx, AV_LOG_ERROR, "ff_frame_thread_encoder_init failed\n");
> >  ff_frame_thread_encoder_free(avctx);
> > 
> This has some presumptions: First, it relies on undocumented behaviour
> from av_opt_copy(), see here:
> https://ffmpeg.org/pipermail/ffmpeg-devel/2021-August/283645.html

Its documented after your patch ;)


> Second, you presume that hw_frames_ctx is not set, although it is a
> valid field for an encoder (although no hardware encoder seems to have
> the frame threading flag set). If it were set, it would be freed
> multiple times. (The same goes for several other fields that are not
> supposed to be set by encoders, but IMO that would be a user problem.)

What do you suggest, should i add an av_assert on hw_frames_ctx==NULL ?


> Notice that the second issue exists even when initializing succeeds.

then its unrelated to the patch, of course we still need to fix it.

More specifically, should i change the patch ?
the hw_frames_ctx seems a bug but unrelated, the undocumentedness is
fixed by you.
the code feels fragile and not particularly robust before this already
and fixing this adding nicer and robust API for all steps cant be backported
and i need to backport the fix so we need a fix without new API

thx

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Everything should be made as simple as possible, but not simpler.
-- Albert Einstein


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] avcodec/frame_thread_encoder: Free AVCodecContext structure on error during init

[Michael Niedermayer]

On Fri, Aug 13, 2021 at 03:22:41PM -0300, James Almer wrote:
> On 8/13/2021 2:48 PM, Michael Niedermayer wrote:
> > Fixes: MemLeak
> > Fixes: 8281
> > Fixes: PoC_option158.jpg
> > Fixes: CVE-2020-22037
> > 
> > Signed-off-by: Michael Niedermayer 
> > ---
> >   libavcodec/frame_thread_encoder.c | 10 ++
> >   1 file changed, 6 insertions(+), 4 deletions(-)
> > 
> > diff --git a/libavcodec/frame_thread_encoder.c 
> > b/libavcodec/frame_thread_encoder.c
> > index 9cabfc495f..25a308173d 100644
> > --- a/libavcodec/frame_thread_encoder.c
> > +++ b/libavcodec/frame_thread_encoder.c
> > @@ -126,7 +126,7 @@ int ff_frame_thread_encoder_init(AVCodecContext *avctx)
> >   {
> >   int i=0;
> >   ThreadContext *c;
> > -
> > +AVCodecContext *thread_avctx = NULL;
> >   if(   !(avctx->thread_type & FF_THREAD_FRAME)
> >  || !(avctx->codec->capabilities & AV_CODEC_CAP_FRAME_THREADS))
> > @@ -202,16 +202,16 @@ int ff_frame_thread_encoder_init(AVCodecContext 
> > *avctx)
> >   for(i=0; ithread_count ; i++){
> >   int ret;
> >   void *tmpv;
> > -AVCodecContext *thread_avctx = 
> > avcodec_alloc_context3(avctx->codec);
> > +thread_avctx = avcodec_alloc_context3(avctx->codec);
> >   if(!thread_avctx)
> >   goto fail;
> >   tmpv = thread_avctx->priv_data;
> >   *thread_avctx = *avctx;
> > +thread_avctx->priv_data = tmpv;
> > +thread_avctx->internal = NULL;
> >   ret = av_opt_copy(thread_avctx, avctx);
> >   if (ret < 0)
> >   goto fail;
> > -thread_avctx->priv_data = tmpv;
> > -thread_avctx->internal = NULL;
> >   if (avctx->codec->priv_class) {
> >   int ret = av_opt_copy(thread_avctx->priv_data, 
> > avctx->priv_data);
> >   if (ret < 0)
> > @@ -233,6 +233,8 @@ int ff_frame_thread_encoder_init(AVCodecContext *avctx)
> >   return 0;
> >   fail:
> > +avcodec_close(thread_avctx);
> > +av_freep(_avctx);
> >   avctx->thread_count = i;
> >   av_log(avctx, AV_LOG_ERROR, "ff_frame_thread_encoder_init failed\n");
> >   ff_frame_thread_encoder_free(avctx);
> 
> Should be ok.

will apply
thx

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

No great genius has ever existed without some touch of madness. -- Aristotle


signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] avcodec/frame_thread_encoder: Free AVCodecContext structure on error during init

[Andreas Rheinhardt]

Michael Niedermayer:
> Fixes: MemLeak
> Fixes: 8281
> Fixes: PoC_option158.jpg
> Fixes: CVE-2020-22037
> 
> Signed-off-by: Michael Niedermayer 
> ---
>  libavcodec/frame_thread_encoder.c | 10 ++
>  1 file changed, 6 insertions(+), 4 deletions(-)
> 
> diff --git a/libavcodec/frame_thread_encoder.c 
> b/libavcodec/frame_thread_encoder.c
> index 9cabfc495f..25a308173d 100644
> --- a/libavcodec/frame_thread_encoder.c
> +++ b/libavcodec/frame_thread_encoder.c
> @@ -126,7 +126,7 @@ int ff_frame_thread_encoder_init(AVCodecContext *avctx)
>  {
>  int i=0;
>  ThreadContext *c;
> -
> +AVCodecContext *thread_avctx = NULL;
>  
>  if(   !(avctx->thread_type & FF_THREAD_FRAME)
> || !(avctx->codec->capabilities & AV_CODEC_CAP_FRAME_THREADS))
> @@ -202,16 +202,16 @@ int ff_frame_thread_encoder_init(AVCodecContext *avctx)
>  for(i=0; ithread_count ; i++){
>  int ret;
>  void *tmpv;
> -AVCodecContext *thread_avctx = avcodec_alloc_context3(avctx->codec);
> +thread_avctx = avcodec_alloc_context3(avctx->codec);
>  if(!thread_avctx)
>  goto fail;
>  tmpv = thread_avctx->priv_data;
>  *thread_avctx = *avctx;
> +thread_avctx->priv_data = tmpv;
> +thread_avctx->internal = NULL;
>  ret = av_opt_copy(thread_avctx, avctx);
>  if (ret < 0)
>  goto fail;
> -thread_avctx->priv_data = tmpv;
> -thread_avctx->internal = NULL;
>  if (avctx->codec->priv_class) {
>  int ret = av_opt_copy(thread_avctx->priv_data, avctx->priv_data);
>  if (ret < 0)
> @@ -233,6 +233,8 @@ int ff_frame_thread_encoder_init(AVCodecContext *avctx)
>  
>  return 0;
>  fail:
> +avcodec_close(thread_avctx);
> +av_freep(_avctx);
>  avctx->thread_count = i;
>  av_log(avctx, AV_LOG_ERROR, "ff_frame_thread_encoder_init failed\n");
>  ff_frame_thread_encoder_free(avctx);
> 
This has some presumptions: First, it relies on undocumented behaviour
from av_opt_copy(), see here:
https://ffmpeg.org/pipermail/ffmpeg-devel/2021-August/283645.html
Second, you presume that hw_frames_ctx is not set, although it is a
valid field for an encoder (although no hardware encoder seems to have
the frame threading flag set). If it were set, it would be freed
multiple times. (The same goes for several other fields that are not
supposed to be set by encoders, but IMO that would be a user problem.)
Notice that the second issue exists even when initializing succeeds.
(@James: Using avcodec_free_context() is even more problematic because
this also frees (intra|inter)_matrix, to fields which are allowed to be
set by the user. It also frees rc_override although the documentation
says it is freed by the user.)

- Andreas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] avcodec/frame_thread_encoder: Free AVCodecContext structure on error during init

[James Almer]

On 8/13/2021 2:48 PM, Michael Niedermayer wrote:

Fixes: MemLeak
Fixes: 8281
Fixes: PoC_option158.jpg
Fixes: CVE-2020-22037

Signed-off-by: Michael Niedermayer 
---
  libavcodec/frame_thread_encoder.c | 10 ++
  1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/libavcodec/frame_thread_encoder.c 
b/libavcodec/frame_thread_encoder.c
index 9cabfc495f..25a308173d 100644
--- a/libavcodec/frame_thread_encoder.c
+++ b/libavcodec/frame_thread_encoder.c
@@ -126,7 +126,7 @@ int ff_frame_thread_encoder_init(AVCodecContext *avctx)
  {
  int i=0;
  ThreadContext *c;
-
+AVCodecContext *thread_avctx = NULL;
  
  if(   !(avctx->thread_type & FF_THREAD_FRAME)

 || !(avctx->codec->capabilities & AV_CODEC_CAP_FRAME_THREADS))
@@ -202,16 +202,16 @@ int ff_frame_thread_encoder_init(AVCodecContext *avctx)
  for(i=0; ithread_count ; i++){
  int ret;
  void *tmpv;
-AVCodecContext *thread_avctx = avcodec_alloc_context3(avctx->codec);
+thread_avctx = avcodec_alloc_context3(avctx->codec);
  if(!thread_avctx)
  goto fail;
  tmpv = thread_avctx->priv_data;
  *thread_avctx = *avctx;
+thread_avctx->priv_data = tmpv;
+thread_avctx->internal = NULL;
  ret = av_opt_copy(thread_avctx, avctx);
  if (ret < 0)
  goto fail;
-thread_avctx->priv_data = tmpv;
-thread_avctx->internal = NULL;
  if (avctx->codec->priv_class) {
  int ret = av_opt_copy(thread_avctx->priv_data, avctx->priv_data);
  if (ret < 0)
@@ -233,6 +233,8 @@ int ff_frame_thread_encoder_init(AVCodecContext *avctx)
  
  return 0;

  fail:
+avcodec_close(thread_avctx);
+av_freep(_avctx);
  avctx->thread_count = i;
  av_log(avctx, AV_LOG_ERROR, "ff_frame_thread_encoder_init failed\n");
  ff_frame_thread_encoder_free(avctx);


Should be ok.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [RFC] Suggestion for a Nicer Integration with GitHub

[Michael Niedermayer]

On Fri, Aug 13, 2021 at 03:14:36PM +, Soft Works wrote:
[...]
> > You do not need anybody's permission either to set up a gateway that
> > will re-post GitHub's PR and comments to the mailing-list and
> > reciprocally
> 
> I would need permission to github/ffmpeg/ffmpeg in order to set
> up the automation hooks.

what exactly is needed to be done, what exact permission is needed
are we talking about adding a link  /API key somewhere or
continues maintaince of some parameters which require specific
permissions?


> 
> Also I wouldn't do it as long as there is at least some kind
> of "let's try it out as an experiment" feedback from here.

I think ultimately none of us knows how it would look/behave before
its done. So its hard to avoid that it would be an experiment


> 
> 
> > If it results in noise on the mailing list, like mails
> > without context quote and flawed patches, you will be firmly asked to
> > disable it. This is the result I expect, because if you make posting
> > to
> > the mailing-list as easy as three clicks, you may get a few competent
> > people who find mailing-lists annoying, but you will mostly enable
> > idiots who cannot do four clicks and a few keystrokes in sequence.
> 
> It is really not my intention to generate noise on the ML from 
> low-quality PRs.
> GGG maintains a list of developers who are allowed to submit
> patches to the ML from a GitHub PR. 
> If you are not on that list, you need one of those who already
> have permission to approve you (= add to this list).
> 
> So for a first-time submitter the procedure would be as follows:
> 
> - Create your PR
>   (but not allowed to submit it to the ML)
> - Find a developer who has permission, point him to your PR
>   and ask for approval to submit to the ML
> - Existing developer might approve you 
> - You can post "/submit" as a comment in your PR and only then
>   it would be sent to the ML
> 
> With that mechanism in place, I wouldn't be concerned that much
> about the mailing list getting spammed by nonsense PRs.

I do not know "GGG", but what happens once a PR is submitted to the ML?
People will write replies on the ML to comment, ask for changes and so forth.
Simlarly on github PRs can receive comments, reviews, approvals and so on
is there some routing of such comments between PR and ML ?

another thing needed, if we would allow PRs is that automated fate testing
of such PRs should be implemented. Thats a great way to filter out bad PRs
beyond just a author list

Thanks

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

No great genius has ever existed without some touch of madness. -- Aristotle


signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH] avcodec/frame_thread_encoder: Free AVCodecContext structure on error during init

[Michael Niedermayer]

Fixes: MemLeak
Fixes: 8281
Fixes: PoC_option158.jpg
Fixes: CVE-2020-22037

Signed-off-by: Michael Niedermayer 
---
 libavcodec/frame_thread_encoder.c | 10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/libavcodec/frame_thread_encoder.c 
b/libavcodec/frame_thread_encoder.c
index 9cabfc495f..25a308173d 100644
--- a/libavcodec/frame_thread_encoder.c
+++ b/libavcodec/frame_thread_encoder.c
@@ -126,7 +126,7 @@ int ff_frame_thread_encoder_init(AVCodecContext *avctx)
 {
 int i=0;
 ThreadContext *c;
-
+AVCodecContext *thread_avctx = NULL;
 
 if(   !(avctx->thread_type & FF_THREAD_FRAME)
|| !(avctx->codec->capabilities & AV_CODEC_CAP_FRAME_THREADS))
@@ -202,16 +202,16 @@ int ff_frame_thread_encoder_init(AVCodecContext *avctx)
 for(i=0; ithread_count ; i++){
 int ret;
 void *tmpv;
-AVCodecContext *thread_avctx = avcodec_alloc_context3(avctx->codec);
+thread_avctx = avcodec_alloc_context3(avctx->codec);
 if(!thread_avctx)
 goto fail;
 tmpv = thread_avctx->priv_data;
 *thread_avctx = *avctx;
+thread_avctx->priv_data = tmpv;
+thread_avctx->internal = NULL;
 ret = av_opt_copy(thread_avctx, avctx);
 if (ret < 0)
 goto fail;
-thread_avctx->priv_data = tmpv;
-thread_avctx->internal = NULL;
 if (avctx->codec->priv_class) {
 int ret = av_opt_copy(thread_avctx->priv_data, avctx->priv_data);
 if (ret < 0)
@@ -233,6 +233,8 @@ int ff_frame_thread_encoder_init(AVCodecContext *avctx)
 
 return 0;
 fail:
+avcodec_close(thread_avctx);
+av_freep(_avctx);
 avctx->thread_count = i;
 av_log(avctx, AV_LOG_ERROR, "ff_frame_thread_encoder_init failed\n");
 ff_frame_thread_encoder_free(avctx);
-- 
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 1/2] imgutils: expose av_image_copy_plane_uc_from()

[Lynne]

Aug 10, 2021, 17:50 by d...@lynne.ee:

> 10 Aug 2021, 17:29 by andreas.rheinha...@outlook.com:
>
>> Lynne:
>>
>>> diff --git a/libavutil/version.h b/libavutil/version.h
>>>
>>> index 6b4a265457..678cb9bfa6 100644
>>>
>>> --- a/libavutil/version.h
>>>
>>> +++ b/libavutil/version.h
>>>
>>> @@ -80,7 +80,7 @@
>>>
>>>
>>>
>>> #define LIBAVUTIL_VERSION_MAJOR  57
>>>
>>> #define LIBAVUTIL_VERSION_MINOR   3
>>>
>>> -#define LIBAVUTIL_VERSION_MICRO 100
>>>
>>> +#define LIBAVUTIL_VERSION_MICRO 101
>>>
>>>
>>>
>>> #define LIBAVUTIL_VERSION_INT   AV_VERSION_INT(LIBAVUTIL_VERSION_MAJOR, \
>>>
>>> LIBAVUTIL_VERSION_MINOR, \
>>>
>>
>> An new function always needs a minor bump.
>>
>> - Andreas
>>
>
> Thanks, changed locally to a minor bump instead.
>

Will push this later tonight.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] avcodec/frame_thread_encoder: Free AVCodecContext structure on error during init

[Michael Niedermayer]

On Thu, Aug 12, 2021 at 05:16:30PM -0300, James Almer wrote:
> On 8/12/2021 5:03 PM, Michael Niedermayer wrote:
> > Fixes: MemLeak
> > Fixes: 8281
> > Fixes: PoC_option158.jpg
> > Fixes: CVE-2020-22037
> > 
> > Signed-off-by: Michael Niedermayer 
> > ---
> >   libavcodec/frame_thread_encoder.c | 7 ---
> >   1 file changed, 4 insertions(+), 3 deletions(-)
> > 
> > diff --git a/libavcodec/frame_thread_encoder.c 
> > b/libavcodec/frame_thread_encoder.c
> > index 9cabfc495f..4a56fedc9d 100644
> > --- a/libavcodec/frame_thread_encoder.c
> > +++ b/libavcodec/frame_thread_encoder.c
> > @@ -126,7 +126,7 @@ int ff_frame_thread_encoder_init(AVCodecContext *avctx)
> >   {
> >   int i=0;
> >   ThreadContext *c;
> > -
> > +AVCodecContext *thread_avctx = NULL;
> >   if(   !(avctx->thread_type & FF_THREAD_FRAME)
> >  || !(avctx->codec->capabilities & AV_CODEC_CAP_FRAME_THREADS))
> > @@ -198,11 +198,10 @@ int ff_frame_thread_encoder_init(AVCodecContext 
> > *avctx)
> >   !(c->tasks[i].outdata = av_packet_alloc()))
> >   goto fail;
> >   }
> > -
> >   for(i=0; ithread_count ; i++){
> >   int ret;
> >   void *tmpv;
> > -AVCodecContext *thread_avctx = 
> > avcodec_alloc_context3(avctx->codec);
> > +thread_avctx = avcodec_alloc_context3(avctx->codec);
> >   if(!thread_avctx)
> >   goto fail;
> >   tmpv = thread_avctx->priv_data;
> > @@ -225,6 +224,7 @@ int ff_frame_thread_encoder_init(AVCodecContext *avctx)
> >   av_assert0(!thread_avctx->internal->frame_thread_encoder);
> >   thread_avctx->internal->frame_thread_encoder = c;
> >   if(pthread_create(>worker[i], NULL, worker, thread_avctx)) {
> > +avcodec_close(thread_avctx);
> 
> If I'm reading this right, there are two av_opt_copy() above that may leak
> if you don't call avcodec_close() on all failure paths after them.
> It should be safe to call it even before avcodec_open2() (or if that
> failed), and even if the argument passed to it is NULL, so might as well
> call it below after the fail label. Or could even use
> avcodec_free_context(), assuming it's safe, and remove the av_freep().

calling avcodec_close() immedeatly after fail crashes the code 
during multiple fate tests if one forces the error path to be taken after the
first av_opt_copy()

Ill post a patch that reorders things a bit so this is working

Thanks


[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

What does censorship reveal? It reveals fear. -- Julian Assange


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] avutil/frame: add av_frame_replace

[Andreas Rheinhardt]

James Almer:
> On 8/13/2021 12:27 PM, Andreas Rheinhardt wrote:
>> James Almer:
>>> Signed-off-by: James Almer 
>>> ---
>>> Not going to bother with implementing replace for side data, since
>>> it's IMO not
>>> worth it, but patches are welcome of course.
>>>
>>> Missing version bump and APIchanges entry.
>>>
>>>   libavutil/frame.c | 98 +++
>>>   libavutil/frame.h | 18 +
>>>   2 files changed, 116 insertions(+)
>>>
>>> diff --git a/libavutil/frame.h b/libavutil/frame.h
>>> index ff2540a20f..36ed128886 100644
>>> --- a/libavutil/frame.h
>>> +++ b/libavutil/frame.h
>>> @@ -695,6 +695,24 @@ void av_frame_free(AVFrame **frame);
>>>    */
>>>   int av_frame_ref(AVFrame *dst, const AVFrame *src);
>>>   +/**
>>> + * Ensure the destination frame refers to the same data described by
>>> the source
>>> + * frame.
>>> + *
>>> + * Copy frame properties from src to dst and create a new reference
>>> for each
>>> + * AVBufferRef from src if they differ from those in dst.
>>> + *
>>> + * src must be reference counted.
>>> + *
>>> + * @param src The source frame. If there's data described in it, it
>>> must be
>>> + *    reference counted.
>>> + * @param dst The destination frame.
>>> + *
>>> + * @return 0 on success, a negative AVERROR on error. On error, dst is
>>> + * unreferenced.
>>> + */
>>> +int av_frame_replace(AVFrame *dst, const AVFrame *src);
>>> +
>>>   /**
>>>    * Create a new frame that references the same data as src.
>>>    *
>>>
>> av_buffer_replace() is a no-op if src == dst (and documented to be so);
>> this is not true for this function where you instantly wipe side data.
> 
> Like i said above, I'm not going to try and implement replace for side
> data. It's just not worth the extra complexity.
> 
I don't think you got my comment: It was not about saving allocations
for side data; it is about what happens when src and dst coincide.
According to the documentation, you should do nothing, because src and
dst already refer to the same data. Instead you wipe the side data and
modify the frame.

- Andreas
___
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] avutil/frame: add av_frame_replace

[James Almer]

On 8/13/2021 12:27 PM, Andreas Rheinhardt wrote:

James Almer:

Signed-off-by: James Almer 
---
Not going to bother with implementing replace for side data, since it's IMO not
worth it, but patches are welcome of course.

Missing version bump and APIchanges entry.

  libavutil/frame.c | 98 +++
  libavutil/frame.h | 18 +
  2 files changed, 116 insertions(+)

diff --git a/libavutil/frame.h b/libavutil/frame.h
index ff2540a20f..36ed128886 100644
--- a/libavutil/frame.h
+++ b/libavutil/frame.h
@@ -695,6 +695,24 @@ void av_frame_free(AVFrame **frame);
   */
  int av_frame_ref(AVFrame *dst, const AVFrame *src);
  
+/**

+ * Ensure the destination frame refers to the same data described by the source
+ * frame.
+ *
+ * Copy frame properties from src to dst and create a new reference for each
+ * AVBufferRef from src if they differ from those in dst.
+ *
+ * src must be reference counted.
+ *
+ * @param src The source frame. If there's data described in it, it must be
+ *reference counted.
+ * @param dst The destination frame.
+ *
+ * @return 0 on success, a negative AVERROR on error. On error, dst is
+ * unreferenced.
+ */
+int av_frame_replace(AVFrame *dst, const AVFrame *src);
+
  /**
   * Create a new frame that references the same data as src.
   *


av_buffer_replace() is a no-op if src == dst (and documented to be so);
this is not true for this function where you instantly wipe side data.


Like i said above, I'm not going to try and implement replace for side 
data. It's just not worth the extra complexity.




- Andreas
___
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 1/3] avutil/frame: add av_frame_replace

[Andreas Rheinhardt]

James Almer:
> Signed-off-by: James Almer 
> ---
> Not going to bother with implementing replace for side data, since it's IMO 
> not
> worth it, but patches are welcome of course.
> 
> Missing version bump and APIchanges entry.
> 
>  libavutil/frame.c | 98 +++
>  libavutil/frame.h | 18 +
>  2 files changed, 116 insertions(+)
> 
> diff --git a/libavutil/frame.h b/libavutil/frame.h
> index ff2540a20f..36ed128886 100644
> --- a/libavutil/frame.h
> +++ b/libavutil/frame.h
> @@ -695,6 +695,24 @@ void av_frame_free(AVFrame **frame);
>   */
>  int av_frame_ref(AVFrame *dst, const AVFrame *src);
>  
> +/**
> + * Ensure the destination frame refers to the same data described by the 
> source
> + * frame.
> + *
> + * Copy frame properties from src to dst and create a new reference for each
> + * AVBufferRef from src if they differ from those in dst.
> + *
> + * src must be reference counted.
> + *
> + * @param src The source frame. If there's data described in it, it must be
> + *reference counted.
> + * @param dst The destination frame.
> + *
> + * @return 0 on success, a negative AVERROR on error. On error, dst is
> + * unreferenced.
> + */
> +int av_frame_replace(AVFrame *dst, const AVFrame *src);
> +
>  /**
>   * Create a new frame that references the same data as src.
>   *
> 
av_buffer_replace() is a no-op if src == dst (and documented to be so);
this is not true for this function where you instantly wipe side data.

- Andreas
___
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] avutil/frame: add av_frame_replace

[James Almer]

On 8/13/2021 12:22 PM, Andreas Rheinhardt wrote:

James Almer:

On 8/10/2021 6:59 PM, James Almer wrote:

Signed-off-by: James Almer 
---
Not going to bother with implementing replace for side data, since
it's IMO not
worth it, but patches are welcome of course.

Missing version bump and APIchanges entry.

   libavutil/frame.c | 98 +++
   libavutil/frame.h | 18 +
   2 files changed, 116 insertions(+)


Will apply the set if there are no objections.


How many allocations are saved by this normally? (I.e. with a random
H.264 file you have)?


I looked at a VP9 file with patch 4/4, and it seemed to remove about a 
third of the overall allocations.




- Andreas
___
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 1/3] avutil/frame: add av_frame_replace

[Andreas Rheinhardt]

James Almer:
> On 8/10/2021 6:59 PM, James Almer wrote:
>> Signed-off-by: James Almer 
>> ---
>> Not going to bother with implementing replace for side data, since
>> it's IMO not
>> worth it, but patches are welcome of course.
>>
>> Missing version bump and APIchanges entry.
>>
>>   libavutil/frame.c | 98 +++
>>   libavutil/frame.h | 18 +
>>   2 files changed, 116 insertions(+)
> 
> Will apply the set if there are no objections.

How many allocations are saved by this normally? (I.e. with a random
H.264 file you have)?

- Andreas
___
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] avutil/frame: add av_frame_replace

[James Almer]

On 8/10/2021 6:59 PM, James Almer wrote:

Signed-off-by: James Almer 
---
Not going to bother with implementing replace for side data, since it's IMO not
worth it, but patches are welcome of course.

Missing version bump and APIchanges entry.

  libavutil/frame.c | 98 +++
  libavutil/frame.h | 18 +
  2 files changed, 116 insertions(+)


Will apply the set if there are no objections.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [RFC] Suggestion for a Nicer Integration with GitHub

[Soft Works]

> -Original Message-
> From: ffmpeg-devel  On Behalf Of
> Nicolas George
> Sent: Friday, 13 August 2021 11:54
> To: FFmpeg development discussions and patches  de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [RFC] Suggestion for a Nicer Integration
> with GitHub
> 

Hi Nicholas,

Thanks for a reasonable reply this time.

Let me re-order a bit and focus on the productive parts:

> On the other hand, if your sole contribution here is to say "you
> should
> do that", then you will probably get nowhere.

Developing something like this from scratch would have been outside
of my available time frame, but adapting and setting up the GGG 
implementation for ffmpeg is something I would in fact offer
to volunteer for.

> You do not need anybody's permission either to set up a gateway that
> will re-post GitHub's PR and comments to the mailing-list and
> reciprocally

I would need permission to github/ffmpeg/ffmpeg in order to set
up the automation hooks.

Also I wouldn't do it as long as there is at least some kind
of "let's try it out as an experiment" feedback from here.


> If it results in noise on the mailing list, like mails
> without context quote and flawed patches, you will be firmly asked to
> disable it. This is the result I expect, because if you make posting
> to
> the mailing-list as easy as three clicks, you may get a few competent
> people who find mailing-lists annoying, but you will mostly enable
> idiots who cannot do four clicks and a few keystrokes in sequence.

It is really not my intention to generate noise on the ML from 
low-quality PRs.
GGG maintains a list of developers who are allowed to submit
patches to the ML from a GitHub PR. 
If you are not on that list, you need one of those who already
have permission to approve you (= add to this list).

So for a first-time submitter the procedure would be as follows:

- Create your PR
  (but not allowed to submit it to the ML)
- Find a developer who has permission, point him to your PR
  and ask for approval to submit to the ML
- Existing developer might approve you 
- You can post "/submit" as a comment in your PR and only then
  it would be sent to the ML

With that mechanism in place, I wouldn't be concerned that much
about the mailing list getting spammed by nonsense PRs.

softworkz

___
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] Consulting request video pre-processing for media project involving machine learning

[Mario Winkler]

Dear Developers

I direct a media project involving a huge variety of online available videos. 
We will analyse these videos with available and state of the art machine 
learning tools, but need to pre-process the videos and bring them to a certain 
standard.

We are looking for somebody to consult to automated pre-process the videos.

The videos we have collected by now:
3 videos downloaded from different sources (YouTube, IG, Tiktok) and with a 
huge variety in quality, length, size, bitrate and format. 300GB total size.

Goal of the preprocessing (TBD):
- remove black bars
- remove items added to the video by 3rd parties (like ’this is my YouTube 
channel’ before the actual video starts) etc.
- similar framerate
- similar codec
- similar bitrate

I just learned from your software, but feel like you might be the right fit to 
help us with this.
If you are interested, please contact me and I will setup a call.

Best,
Mario
___
Mario Winkler Company LLC is specialised for Project Management of 
International Contemporary Art Projects. We are closing the gaps and and 
sometimes buffer to make any artist visions reality. 


Mario Winkler Company GmbH
Bernerstrasse Nord 180 CH-8064 Zürich
office +41 55 552 03 00  / m...@mariowinkler.ch
direct +41 76 566 36 27 / ma...@mariowinkler.ch
Instagram 

This email and any attachments to it may be confidential and are
intended solely for the use of the individual to whom it is addressed.
If you are not the intended recipient of this email, you must neither
take any action based upon its contents, nor copy or show it to anyone.
Please contact the sender if you have received this email in error

___
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] [FFmpeg-cvslog] Fix for bug #9231: B-frames parameter is ignored in videotoolboxenc

[Richard Kern]

> On Aug 13, 2021, at 9:12 AM, Nicolas George  wrote:
> 
> Anselm Busse (12021-08-13):
>> Fix for bug #9231: B-frames parameter is ignored in videotoolboxenc
> 
> To whoever pushed this: this is not a correct first line for a commit
> message. It should have been something like:
> 
> libavc/videotoolboxenc: do not override B-frames parameter.
Ok, I’ll pay more attention to this. 

> 
> i.e.: first a context before a colon, and then what the patch does, not
> what was wrong before.
> 
> And "Fix track ticket #9231" somewhere below.
> 
> It is not a grave mistake, but please be more careful next time.
> 
> Regards,
> 
> -- 
>  Nicolas George
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
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] Fix for bug #9231: B-frames parameter is ignored in videotoolboxenc

[Rick Kern]

On Fri, Aug 13, 2021 at 5:39 AM "zhilizhao(赵志立)" 
wrote:

>
>
> > On Aug 13, 2021, at 3:00 PM, Anselm Busse 
> wrote:
> >
> > Hey everyone,
> >
> > I posted this patch almost a month ago and got no reaction. Is there
> anything else I have to/can do to get this fix merged? I’m a little bit
> worried that it gets lost.
>
Sorry for the delay. The patch is applied, thanks.


>
> LGTM.
>
> >
> > - Anselm
> >
> >> Am 21.07.2021 um 20:00 schrieb Anselm Busse :
> >>
> >> This commit fixes the bug as report in
> https://trac.ffmpeg.org/ticket/9231 by removing the line that overwrites
> the user settings for max_b_frames.
> >>
> >> Signed-off-by: Anselm Busse 
> >> ---
> >> libavcodec/videotoolboxenc.c | 1 -
> >> 1 file changed, 1 deletion(-)
> >>
> >> diff --git a/libavcodec/videotoolboxenc.c b/libavcodec/videotoolboxenc.c
> >> index 4eaabed5d8..8dfd6e3d0c 100644
> >> --- a/libavcodec/videotoolboxenc.c
> >> +++ b/libavcodec/videotoolboxenc.c
> >> @@ -1398,7 +1398,6 @@ static int vtenc_configure_encoder(AVCodecContext
> *avctx)
> >>}
> >>
> >>vtctx->codec_id = avctx->codec_id;
> >> -avctx->max_b_frames = 16;
> >>
> >>if (vtctx->codec_id == AV_CODEC_ID_H264) {
> >>vtctx->get_param_set_func =
> CMVideoFormatDescriptionGetH264ParameterSetAtIndex;
> >> --
> >> 2.32.0
> >>
> >
> > ___
> > ffmpeg-devel mailing list
> > ffmpeg-devel@ffmpeg.org
> > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> >
> > To unsubscribe, visit link above, or email
> > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
>
> ___
> ffmpeg-devel 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] [FFmpeg-cvslog] Fix for bug #9231: B-frames parameter is ignored in videotoolboxenc

[Nicolas George]

Anselm Busse (12021-08-13):
> Fix for bug #9231: B-frames parameter is ignored in videotoolboxenc

To whoever pushed this: this is not a correct first line for a commit
message. It should have been something like:

libavc/videotoolboxenc: do not override B-frames parameter.

i.e.: first a context before a colon, and then what the patch does, not
what was wrong before.

And "Fix track ticket #9231" somewhere below.

It is not a grave mistake, but please be more careful next time.

Regards,

-- 
  Nicolas George


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] lavc/videotoolboxenc.c: Add trc for iec61966-2-1 when available

[Rick Kern]

On Fri, Jul 23, 2021 at 4:31 AM Hao Guan  wrote:

> Signed-off-by: Hao Guan 
> ---
>
> Notes:
> I have checked out the code about other functions introduced after
> macOS 10.13 and noticed that the availability is checked during configure.
> Therefore I add the check for sRGB function too. It should compile now.
>
>  configure| 2 ++
>  libavcodec/videotoolboxenc.c | 5 +
>  2 files changed, 7 insertions(+)
>
> diff --git a/configure b/configure
> index bb6b096414..644d9f3537 100755
> --- a/configure
> +++ b/configure
> @@ -2325,6 +2325,7 @@ TYPES_LIST="
>  kCVImageBufferTransferFunction_SMPTE_ST_2084_PQ
>  kCVImageBufferTransferFunction_ITU_R_2100_HLG
>  kCVImageBufferTransferFunction_Linear
> +kCVImageBufferTransferFunction_sRGB
>  socklen_t
>  struct_addrinfo
>  struct_group_source_req
> @@ -6278,6 +6279,7 @@ enabled videotoolbox && {
>  check_func_headers CoreVideo/CVImageBuffer.h
> kCVImageBufferTransferFunction_SMPTE_ST_2084_PQ "-framework CoreVideo"
>  check_func_headers CoreVideo/CVImageBuffer.h
> kCVImageBufferTransferFunction_ITU_R_2100_HLG "-framework CoreVideo"
>  check_func_headers CoreVideo/CVImageBuffer.h
> kCVImageBufferTransferFunction_Linear "-framework CoreVideo"
> +check_func_headers CoreVideo/CVImageBuffer.h
> kCVImageBufferTransferFunction_sRGB "-framework CoreVideo"
>
Instead of being checked at build time, this should be checked at runtime
by adding it to compat_keys in videotoolboxenc.c. The reason is newer MacOS
versions will compile with this symbol, but if the build is targeting an
older MacOS version, it will crash on the older version because it can't
find the symbol.

 }
>
>  check_struct "sys/time.h sys/resource.h" "struct rusage" ru_maxrss
> diff --git a/libavcodec/videotoolboxenc.c b/libavcodec/videotoolboxenc.c
> index 4eaabed5d8..4cba781e9b 100644
> --- a/libavcodec/videotoolboxenc.c
> +++ b/libavcodec/videotoolboxenc.c
> @@ -977,6 +977,11 @@ static int get_cv_transfer_function(AVCodecContext
> *avctx,
>  *transfer_fnc = kCVImageBufferTransferFunction_ITU_R_2100_HLG;
>  break;
>  #endif
> +#if HAVE_KCVIMAGEBUFFERTRANSFERFUNCTION_SRGB
> +case AVCOL_TRC_IEC61966_2_1:
> +*transfer_fnc = kCVImageBufferTransferFunction_sRGB;
> +break;
> +#endif
>
>  case AVCOL_TRC_GAMMA22:
>  gamma = 2.2;
> --
> 2.30.1 (Apple Git-130)
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH v4 4/4] avdevice/decklink: support for more duplex mode for Decklink 8K Pro

[lance . lmwang]

From: Limin Wang 

Reviewed-by: Marton Balint 
Signed-off-by: Limin Wang 
---
 doc/indevs.texi | 16 +++-
 doc/outdevs.texi| 16 +++-
 libavdevice/decklink_common.cpp |  8 ++--
 libavdevice/decklink_common.h   | 11 +++
 libavdevice/decklink_dec_c.c| 10 ++
 libavdevice/decklink_enc_c.c| 10 ++
 libavdevice/version.h   |  2 +-
 7 files changed, 68 insertions(+), 5 deletions(-)

diff --git a/doc/indevs.texi b/doc/indevs.texi
index b377924..5be647f 100644
--- a/doc/indevs.texi
+++ b/doc/indevs.texi
@@ -344,9 +344,23 @@ Defines number of audio channels to capture. Must be 
@samp{2}, @samp{8} or @samp
 Defaults to @samp{2}.
 
 @item duplex_mode
-Sets the decklink device duplex mode. Must be @samp{unset}, @samp{half} or 
@samp{full}.
+Sets the decklink device duplex/profile mode. Must be @samp{unset}, 
@samp{half}, @samp{full},
+@samp{one_sub_device_full}, @samp{one_sub_device_half}, 
@samp{two_sub_device_full},
+@samp{four_sub_device_half}
 Defaults to @samp{unset}.
 
+Note: DeckLink SDK 11.0 have replaced the duplex property by a profile 
property.
+For the DeckLink Duo 2 and DeckLink Quad 2, a profile is shared between any 2
+sub-devices that utilize the same connectors. For the DeckLink 8K Pro, a 
profile
+is shared between all 4 sub-devices. So DeckLink 8K Pro support four profiles.
+
+Valid profile modes for DeckLink 8K Pro(with DeckLink SDK >= 11.0):
+@samp{one_sub_device_full}, @samp{one_sub_device_half}, 
@samp{two_sub_device_full},
+@samp{four_sub_device_half}
+
+Valid profile modes for DeckLink Quad 2 and DeckLink Duo 2:
+@samp{half}, @samp{full}
+
 @item timecode_format
 Timecode type to include in the frame and video stream metadata. Must be
 @samp{none}, @samp{rp188vitc}, @samp{rp188vitc2}, @samp{rp188ltc},
diff --git a/doc/outdevs.texi b/doc/outdevs.texi
index cc0c94a..aa41e29 100644
--- a/doc/outdevs.texi
+++ b/doc/outdevs.texi
@@ -198,9 +198,23 @@ Amount of time to preroll video in seconds.
 Defaults to @option{0.5}.
 
 @item duplex_mode
-Sets the decklink device duplex mode. Must be @samp{unset}, @samp{half} or 
@samp{full}.
+Sets the decklink device duplex/profile mode. Must be @samp{unset}, 
@samp{half}, @samp{full},
+@samp{one_sub_device_full}, @samp{one_sub_device_half}, 
@samp{two_sub_device_full},
+@samp{four_sub_device_half}
 Defaults to @samp{unset}.
 
+Note: DeckLink SDK 11.0 have replaced the duplex property by a profile 
property.
+For the DeckLink Duo 2 and DeckLink Quad 2, a profile is shared between any 2
+sub-devices that utilize the same connectors. For the DeckLink 8K Pro, a 
profile
+is shared between all 4 sub-devices. So DeckLink 8K Pro support four profiles.
+
+Valid profile modes for DeckLink 8K Pro(with DeckLink SDK >= 11.0):
+@samp{one_sub_device_full}, @samp{one_sub_device_half}, 
@samp{two_sub_device_full},
+@samp{four_sub_device_half}
+
+Valid profile modes for DeckLink Quad 2 and DeckLink Duo 2:
+@samp{half}, @samp{full}
+
 @item timing_offset
 Sets the genlock timing pixel offset on the used output.
 Defaults to @samp{unset}.
diff --git a/libavdevice/decklink_common.cpp b/libavdevice/decklink_common.cpp
index 0569462..380c6e5 100644
--- a/libavdevice/decklink_common.cpp
+++ b/libavdevice/decklink_common.cpp
@@ -182,7 +182,11 @@ int ff_decklink_set_configs(AVFormatContext *avctx,
 if (duplex_supported) {
 #if BLACKMAGIC_DECKLINK_API_VERSION >= 0x0b00
 IDeckLinkProfile *profile = NULL;
-BMDProfileID bmd_profile_id = ctx->duplex_mode == 2 ? 
bmdProfileOneSubDeviceFullDuplex : bmdProfileTwoSubDevicesHalfDuplex;
+BMDProfileID bmd_profile_id = NULL;
+
+if (ctx->duplex_mode >= FF_ARRAY_ELEMS(decklink_profile_id_map))
+return EINVAL;
+bmd_profile_id = decklink_profile_id_map[ctx->duplex_mode];
 res = manager->GetProfile(bmd_profile_id, );
 if (res == S_OK) {
 res = profile->SetActive();
@@ -195,7 +199,7 @@ int ff_decklink_set_configs(AVFormatContext *avctx,
 if (res != S_OK)
 av_log(avctx, AV_LOG_WARNING, "Setting duplex mode failed.\n");
 else
-av_log(avctx, AV_LOG_VERBOSE, "Successfully set duplex mode to 
%s duplex.\n", ctx->duplex_mode == 2 ? "full" : "half");
+av_log(avctx, AV_LOG_VERBOSE, "Successfully set duplex mode to 
%s duplex.\n", ctx->duplex_mode == 2 || ctx->duplex_mode == 4 ? "full" : 
"half");
 } else {
 av_log(avctx, AV_LOG_WARNING, "Unable to set duplex mode, because 
it is not supported.\n");
 }
diff --git a/libavdevice/decklink_common.h b/libavdevice/decklink_common.h
index ad8b33c..5b11dcd 100644
--- a/libavdevice/decklink_common.h
+++ b/libavdevice/decklink_common.h
@@ -208,6 +208,17 @@ static const BMDLinkConfiguration decklink_link_conf_map[] 
= {
 bmdLinkConfigurationQuadLink
 };
 
+#if BLACKMAGIC_DECKLINK_API_VERSION >= 

[FFmpeg-devel] [PATCH v4 3/4] avdevice/decklink: add level_a configure

[lance . lmwang]

From: Limin Wang 

Reviewed-by: Marton Balint 
Signed-off-by: Limin Wang 
---
 doc/outdevs.texi|  5 +
 libavdevice/decklink_common.cpp | 17 +
 libavdevice/decklink_common_c.h |  1 +
 libavdevice/decklink_enc_c.c|  4 
 4 files changed, 27 insertions(+)

diff --git a/doc/outdevs.texi b/doc/outdevs.texi
index e3e88b2..cc0c94a 100644
--- a/doc/outdevs.texi
+++ b/doc/outdevs.texi
@@ -216,6 +216,11 @@ Enable Square Division Quad Split mode for Quad-link SDI 
output.
 Must be @samp{unset}, @samp{true} or @samp{false}.
 Defaults to @option{unset}.
 
+@item level_a
+Enable SMPTE Level A mode on the used output.
+Must be @samp{unset}, @samp{true} or @samp{false}.
+Defaults to @option{unset}.
+
 @end table
 
 @subsection Examples
diff --git a/libavdevice/decklink_common.cpp b/libavdevice/decklink_common.cpp
index a892a6c..0569462 100644
--- a/libavdevice/decklink_common.cpp
+++ b/libavdevice/decklink_common.cpp
@@ -230,6 +230,23 @@ int ff_decklink_set_configs(AVFormatContext *avctx,
 }
 }
 
+if (direction == DIRECTION_OUT && cctx->level_a >= 0) {
+DECKLINK_BOOL level_a_supported = false;
+
+if (ctx->attr->GetFlag(BMDDeckLinkSupportsSMPTELevelAOutput, 
_a_supported) != S_OK)
+level_a_supported = false;
+
+if (level_a_supported) {
+res = ctx->cfg->SetFlag(bmdDeckLinkConfigSMPTELevelAOutput, 
cctx->level_a);
+if (res != S_OK)
+av_log(avctx, AV_LOG_WARNING, "Setting SMPTE levelA 
failed.\n");
+else
+av_log(avctx, AV_LOG_VERBOSE, "Successfully set SMPTE 
levelA.\n");
+} else {
+av_log(avctx, AV_LOG_WARNING, "Unable to set SMPTE levelA mode, 
because it is not supported.\n");
+}
+}
+
 return 0;
 }
 
diff --git a/libavdevice/decklink_common_c.h b/libavdevice/decklink_common_c.h
index fdaa1f9..c257721 100644
--- a/libavdevice/decklink_common_c.h
+++ b/libavdevice/decklink_common_c.h
@@ -50,6 +50,7 @@ struct decklink_cctx {
 int duplex_mode;
 int link;
 int sqd;
+int level_a;
 DecklinkPtsSource audio_pts_source;
 DecklinkPtsSource video_pts_source;
 int audio_input;
diff --git a/libavdevice/decklink_enc_c.c b/libavdevice/decklink_enc_c.c
index 4bcdbfe..559f078 100644
--- a/libavdevice/decklink_enc_c.c
+++ b/libavdevice/decklink_enc_c.c
@@ -44,6 +44,10 @@ static const AVOption options[] = {
 { "unset"   ,  NULL , 0   , 
AV_OPT_TYPE_CONST , { .i64 = -1  }, 0, 0, ENC, "sqd"},
 { "false"   ,  NULL , 0   , 
AV_OPT_TYPE_CONST , { .i64 = 0   }, 0, 0, ENC, "sqd"},
 { "true",  NULL , 0   , 
AV_OPT_TYPE_CONST , { .i64 = 1   }, 0, 0, ENC, "sqd"},
+{ "level_a" , "set SMPTE LevelA", OFFSET(level_a) , 
AV_OPT_TYPE_INT,{ .i64 = -1  }, -1,1, ENC, "level_a"},
+{ "unset"   ,  NULL , 0   , 
AV_OPT_TYPE_CONST , { .i64 = -1  }, 0, 0, ENC, "level_a"},
+{ "false"   ,  NULL , 0   , 
AV_OPT_TYPE_CONST , { .i64 = 0   }, 0, 0, ENC, "level_a"},
+{ "true",  NULL , 0   , 
AV_OPT_TYPE_CONST , { .i64 = 1   }, 0, 0, ENC, "level_a"},
 { "timing_offset", "genlock timing pixel offset", OFFSET(timing_offset), 
AV_OPT_TYPE_INT,   { .i64 = INT_MIN }, INT_MIN, INT_MAX, ENC, "timing_offset"},
 { "unset"   ,  NULL , 0, 
AV_OPT_TYPE_CONST, { .i64 = INT_MIN },   0,   0, ENC, "timing_offset"},
 { NULL },
-- 
1.8.3.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 v4 2/4] avdevice/decklink: add sqd configure

[lance . lmwang]

From: Limin Wang 

Reviewed-by: Marton Balint 
Signed-off-by: Limin Wang 
---
 configure   | 2 +-
 doc/outdevs.texi| 5 +
 libavdevice/decklink_common.cpp | 7 +++
 libavdevice/decklink_common_c.h | 1 +
 libavdevice/decklink_enc_c.c| 4 
 5 files changed, 18 insertions(+), 1 deletion(-)

diff --git a/configure b/configure
index 82639ce..af8a934 100755
--- a/configure
+++ b/configure
@@ -6387,7 +6387,7 @@ enabled avisynth  && require_headers 
"avisynth/avisynth_c.h"
 enabled cuda_nvcc && { check_nvcc cuda_nvcc || die "ERROR: failed 
checking for nvcc."; }
 enabled chromaprint   && require chromaprint chromaprint.h 
chromaprint_get_version -lchromaprint
 enabled decklink  && { require_headers DeckLinkAPI.h &&
-   { test_cpp_condition DeckLinkAPIVersion.h 
"BLACKMAGIC_DECKLINK_API_VERSION >= 0x0a0a" || die "ERROR: Decklink API 
version must be >= 10.10"; } }
+   { test_cpp_condition DeckLinkAPIVersion.h 
"BLACKMAGIC_DECKLINK_API_VERSION >= 0x0a0b" || die "ERROR: Decklink API 
version must be >= 10.11"; } }
 enabled frei0r&& require_headers "frei0r.h dlfcn.h"
 enabled gmp   && require gmp gmp.h mpz_export -lgmp
 enabled gnutls&& require_pkg_config gnutls gnutls gnutls/gnutls.h 
gnutls_global_init
diff --git a/doc/outdevs.texi b/doc/outdevs.texi
index f046b23..e3e88b2 100644
--- a/doc/outdevs.texi
+++ b/doc/outdevs.texi
@@ -211,6 +211,11 @@ Sets the SDI video link configuration on the used output. 
Must be
 SDI.
 Defaults to @samp{unset}.
 
+@item sqd
+Enable Square Division Quad Split mode for Quad-link SDI output.
+Must be @samp{unset}, @samp{true} or @samp{false}.
+Defaults to @option{unset}.
+
 @end table
 
 @subsection Examples
diff --git a/libavdevice/decklink_common.cpp b/libavdevice/decklink_common.cpp
index 4e0df04..a892a6c 100644
--- a/libavdevice/decklink_common.cpp
+++ b/libavdevice/decklink_common.cpp
@@ -221,6 +221,13 @@ int ff_decklink_set_configs(AVFormatContext *avctx,
 av_log(avctx, AV_LOG_WARNING, "Setting link configuration 
failed.\n");
 else
 av_log(avctx, AV_LOG_VERBOSE, "Successfully set link 
configuration: 0x%x.\n", ctx->link);
+if (ctx->link == bmdLinkConfigurationQuadLink && cctx->sqd >= 0) {
+res = 
ctx->cfg->SetFlag(bmdDeckLinkConfigQuadLinkSDIVideoOutputSquareDivisionSplit, 
cctx->sqd);
+if (res != S_OK)
+av_log(avctx, AV_LOG_WARNING, "Setting SquareDivisionSplit 
failed.\n");
+else
+av_log(avctx, AV_LOG_VERBOSE, "Successfully set 
SquareDivisionSplit.\n");
+}
 }
 
 return 0;
diff --git a/libavdevice/decklink_common_c.h b/libavdevice/decklink_common_c.h
index f37e0c0..fdaa1f9 100644
--- a/libavdevice/decklink_common_c.h
+++ b/libavdevice/decklink_common_c.h
@@ -49,6 +49,7 @@ struct decklink_cctx {
 int audio_depth;
 int duplex_mode;
 int link;
+int sqd;
 DecklinkPtsSource audio_pts_source;
 DecklinkPtsSource video_pts_source;
 int audio_input;
diff --git a/libavdevice/decklink_enc_c.c b/libavdevice/decklink_enc_c.c
index 4d191d8..4bcdbfe 100644
--- a/libavdevice/decklink_enc_c.c
+++ b/libavdevice/decklink_enc_c.c
@@ -40,6 +40,10 @@ static const AVOption options[] = {
 { "single"  ,  NULL , 0   , 
AV_OPT_TYPE_CONST , { .i64 = 1   }, 0, 0, ENC, "link"},
 { "dual",  NULL , 0   , 
AV_OPT_TYPE_CONST , { .i64 = 2   }, 0, 0, ENC, "link"},
 { "quad",  NULL , 0   , 
AV_OPT_TYPE_CONST , { .i64 = 3   }, 0, 0, ENC, "link"},
+{ "sqd" , "set Square Division" , OFFSET(sqd) , 
AV_OPT_TYPE_INT,{ .i64 = -1  }, -1,1, ENC, "sqd"},
+{ "unset"   ,  NULL , 0   , 
AV_OPT_TYPE_CONST , { .i64 = -1  }, 0, 0, ENC, "sqd"},
+{ "false"   ,  NULL , 0   , 
AV_OPT_TYPE_CONST , { .i64 = 0   }, 0, 0, ENC, "sqd"},
+{ "true",  NULL , 0   , 
AV_OPT_TYPE_CONST , { .i64 = 1   }, 0, 0, ENC, "sqd"},
 { "timing_offset", "genlock timing pixel offset", OFFSET(timing_offset), 
AV_OPT_TYPE_INT,   { .i64 = INT_MIN }, INT_MIN, INT_MAX, ENC, "timing_offset"},
 { "unset"   ,  NULL , 0, 
AV_OPT_TYPE_CONST, { .i64 = INT_MIN },   0,   0, ENC, "timing_offset"},
 { NULL },
-- 
1.8.3.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 v4 1/4] avdevice/decklink: add link configuration

[lance . lmwang]

From: Limin Wang 

Reviewed-by: Marton Balint 
Signed-off-by: Limin Wang 
---
 doc/outdevs.texi| 6 ++
 libavdevice/decklink_common.cpp | 9 +
 libavdevice/decklink_common.h   | 8 
 libavdevice/decklink_common_c.h | 1 +
 libavdevice/decklink_enc.cpp| 2 ++
 libavdevice/decklink_enc_c.c| 5 +
 6 files changed, 31 insertions(+)

diff --git a/doc/outdevs.texi b/doc/outdevs.texi
index aaf2479..f046b23 100644
--- a/doc/outdevs.texi
+++ b/doc/outdevs.texi
@@ -205,6 +205,12 @@ Defaults to @samp{unset}.
 Sets the genlock timing pixel offset on the used output.
 Defaults to @samp{unset}.
 
+@item link
+Sets the SDI video link configuration on the used output. Must be
+@samp{unset}, @samp{single} link SDI, @samp{dual} link SDI or @samp{quad} link
+SDI.
+Defaults to @samp{unset}.
+
 @end table
 
 @subsection Examples
diff --git a/libavdevice/decklink_common.cpp b/libavdevice/decklink_common.cpp
index 24aa9b1..4e0df04 100644
--- a/libavdevice/decklink_common.cpp
+++ b/libavdevice/decklink_common.cpp
@@ -214,6 +214,15 @@ int ff_decklink_set_configs(AVFormatContext *avctx,
 if (res != S_OK)
 av_log(avctx, AV_LOG_WARNING, "Setting timing offset failed.\n");
 }
+
+if (direction == DIRECTION_OUT && ctx->link > 0) {
+res = ctx->cfg->SetInt(bmdDeckLinkConfigSDIOutputLinkConfiguration, 
ctx->link);
+if (res != S_OK)
+av_log(avctx, AV_LOG_WARNING, "Setting link configuration 
failed.\n");
+else
+av_log(avctx, AV_LOG_VERBOSE, "Successfully set link 
configuration: 0x%x.\n", ctx->link);
+}
+
 return 0;
 }
 
diff --git a/libavdevice/decklink_common.h b/libavdevice/decklink_common.h
index 6e03295..ad8b33c 100644
--- a/libavdevice/decklink_common.h
+++ b/libavdevice/decklink_common.h
@@ -131,6 +131,7 @@ struct decklink_ctx {
 int64_t teletext_lines;
 double preroll;
 int duplex_mode;
+BMDLinkConfiguration link;
 DecklinkPtsSource audio_pts_source;
 DecklinkPtsSource video_pts_source;
 int draw_bars;
@@ -200,6 +201,13 @@ static const BMDTimecodeFormat 
decklink_timecode_format_map[] = {
 #endif
 };
 
+static const BMDLinkConfiguration decklink_link_conf_map[] = {
+(BMDLinkConfiguration)0,
+bmdLinkConfigurationSingleLink,
+bmdLinkConfigurationDualLink,
+bmdLinkConfigurationQuadLink
+};
+
 int ff_decklink_set_configs(AVFormatContext *avctx, decklink_direction_t 
direction);
 int ff_decklink_set_format(AVFormatContext *avctx, int width, int height, int 
tb_num, int tb_den, enum AVFieldOrder field_order, decklink_direction_t 
direction = DIRECTION_OUT);
 int ff_decklink_set_format(AVFormatContext *avctx, decklink_direction_t 
direction);
diff --git a/libavdevice/decklink_common_c.h b/libavdevice/decklink_common_c.h
index 68978fa..f37e0c0 100644
--- a/libavdevice/decklink_common_c.h
+++ b/libavdevice/decklink_common_c.h
@@ -48,6 +48,7 @@ struct decklink_cctx {
 int audio_channels;
 int audio_depth;
 int duplex_mode;
+int link;
 DecklinkPtsSource audio_pts_source;
 DecklinkPtsSource video_pts_source;
 int audio_input;
diff --git a/libavdevice/decklink_enc.cpp b/libavdevice/decklink_enc.cpp
index 4c1eb05..6dec5f3 100644
--- a/libavdevice/decklink_enc.cpp
+++ b/libavdevice/decklink_enc.cpp
@@ -559,6 +559,8 @@ av_cold int ff_decklink_write_header(AVFormatContext *avctx)
 ctx->list_formats = cctx->list_formats;
 ctx->preroll  = cctx->preroll;
 ctx->duplex_mode  = cctx->duplex_mode;
+if (cctx->link > 0 && (unsigned int)cctx->link < 
FF_ARRAY_ELEMS(decklink_link_conf_map))
+ctx->link = decklink_link_conf_map[cctx->link];
 cctx->ctx = ctx;
 #if CONFIG_LIBKLVANC
 if (klvanc_context_create(>vanc_ctx) < 0) {
diff --git a/libavdevice/decklink_enc_c.c b/libavdevice/decklink_enc_c.c
index 828cf5d..4d191d8 100644
--- a/libavdevice/decklink_enc_c.c
+++ b/libavdevice/decklink_enc_c.c
@@ -35,6 +35,11 @@ static const AVOption options[] = {
 { "unset"   ,  NULL , 0   , 
AV_OPT_TYPE_CONST , { .i64 = 0   }, 0, 0, ENC, "duplex_mode"},
 { "half",  NULL , 0   , 
AV_OPT_TYPE_CONST , { .i64 = 1   }, 0, 0, ENC, "duplex_mode"},
 { "full",  NULL , 0   , 
AV_OPT_TYPE_CONST , { .i64 = 2   }, 0, 0, ENC, "duplex_mode"},
+{ "link" , "single/dual/quad SDI link configuration", 
OFFSET(link), AV_OPT_TYPE_INT, { .i64 = 0   }, 0, 3, ENC, "link"},
+{ "unset"   ,  NULL , 0   , 
AV_OPT_TYPE_CONST , { .i64 = 0   }, 0, 0, ENC, "link"},
+{ "single"  ,  NULL , 0   , 
AV_OPT_TYPE_CONST , { .i64 = 1   }, 0, 0, ENC, "link"},
+{ "dual",  NULL , 0   , 
AV_OPT_TYPE_CONST , { .i64 = 2   }, 0, 0, ENC, "link"},
+{ "quad",  NULL , 0

Re: [FFmpeg-devel] [RFC] Suggestion for a Nicer Integration with GitHub

[Nicolas George]

Soft Works (12021-08-12):
> Yes, that's not what you wrote, but that attitude was shining out
> between the lines very clearly.

You are entirely responsible for your interpretation and all the
negative consequences it entails.

> > If you want the project to change its way of working to accommodate
> > you
> > before we even know if you will be submitting quality patches for the
> > long run... go grok some PHP or something.

> BTW, I think that would be a great text for the website section 
> "Contributing".

Of course it would be. Unless you are writing this ironically? Do you
really expect a project to kotow to unknown people?

> This is not about developers being incapable to work with the 
> mailing list. 

The proof of the pudding, as they say, is in the eating.

You do not need anybody's permission to set up a meeting place for
wannabe developers to help each other getting up to speed and to add a
pointer to it on the wiki. Nor do you need anybody's permission to look
at patches on the mailing-list, and reply to the ones that have obvious
flaws to direct them to your forum.

If your endeavor results in more patches submitted to the mailing-list
in good shape on the first try, then you would have proved its
usefulness and can expect official support.


You do not need anybody's permission either to set up a gateway that
will re-post GitHub's PR and comments to the mailing-list and
reciprocally. If it results in noise on the mailing list, like mails
without context quote and flawed patches, you will be firmly asked to
disable it. This is the result I expect, because if you make posting to
the mailing-list as easy as three clicks, you may get a few competent
people who find mailing-lists annoying, but you will mostly enable
idiots who cannot do four clicks and a few keystrokes in sequence. But I
would gladly realize I was wrong.


On the other hand, if your sole contribution here is to say "you should
do that", then you will probably get nowhere.

So... bake your pudding, and we will sample it.

> It's about developers being unwilling to participate due to 
> the outdated and inferior (from their pov) tooling.

... But honestly, I doubt somebody who refuses to consider the merits of
our work-flow would be qualified to help newbies to adapt to our
work-flow.

Regards,

-- 
  Nicolas George


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] Fix for bug #9231: B-frames parameter is ignored in videotoolboxenc

[zhilizhao(赵志立)]

> On Aug 13, 2021, at 3:00 PM, Anselm Busse  wrote:
> 
> Hey everyone,
> 
> I posted this patch almost a month ago and got no reaction. Is there anything 
> else I have to/can do to get this fix merged? I’m a little bit worried that 
> it gets lost.

LGTM.

> 
> - Anselm
> 
>> Am 21.07.2021 um 20:00 schrieb Anselm Busse :
>> 
>> This commit fixes the bug as report in https://trac.ffmpeg.org/ticket/9231 
>> by removing the line that overwrites the user settings for max_b_frames.
>> 
>> Signed-off-by: Anselm Busse 
>> ---
>> libavcodec/videotoolboxenc.c | 1 -
>> 1 file changed, 1 deletion(-)
>> 
>> diff --git a/libavcodec/videotoolboxenc.c b/libavcodec/videotoolboxenc.c
>> index 4eaabed5d8..8dfd6e3d0c 100644
>> --- a/libavcodec/videotoolboxenc.c
>> +++ b/libavcodec/videotoolboxenc.c
>> @@ -1398,7 +1398,6 @@ static int vtenc_configure_encoder(AVCodecContext 
>> *avctx)
>>}
>> 
>>vtctx->codec_id = avctx->codec_id;
>> -avctx->max_b_frames = 16;
>> 
>>if (vtctx->codec_id == AV_CODEC_ID_H264) {
>>vtctx->get_param_set_func = 
>> CMVideoFormatDescriptionGetH264ParameterSetAtIndex;
>> -- 
>> 2.32.0
>> 
> 
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

___
ffmpeg-devel 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 v1] lavfi: add nlmeans CUDA filter

[Dylan Fernando]

Any update on this?

Kind Regards,
Dylan
___
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] avutil/opt: Document actual behaviour of av_opt_copy a bit more

[Andreas Rheinhardt]

In particular, document that av_opt_copy() always disentangles
allocated options even on error; this guarantee is needed to e.g.
properly free duplicated thread contexts in libavcodec on error.

Signed-off-by: Andreas Rheinhardt 
---
Missing APIchanges entry and version bump (minor or micro?).

 libavutil/opt.h | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/libavutil/opt.h b/libavutil/opt.h
index 9e1e8ede06..2820435eec 100644
--- a/libavutil/opt.h
+++ b/libavutil/opt.h
@@ -790,9 +790,16 @@ int av_opt_query_ranges(AVOptionRanges **, void *obj, 
const char *key, int flags
 /**
  * Copy options from src object into dest object.
  *
+ * The underlying AVClass of both src and dest must coincide. The guarantee
+ * below does not apply if this is not fulfilled.
+ *
  * Options that require memory allocation (e.g. string or binary) are 
malloc'ed in dest object.
  * Original memory allocated for such options is freed unless both src and 
dest options points to the same memory.
  *
+ * Even on error it is guaranteed that allocated options from src and dest
+ * no longer alias each other afterwards; in particular calling av_opt_free()
+ * on both src and dest is safe afterwards if dest has been memdup'ed from src.
+ *
  * @param dest Object to copy from
  * @param src  Object to copy into
  * @return 0 on success, negative on error
-- 
2.30.2

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] Fix for bug #9231: B-frames parameter is ignored in videotoolboxenc

[Anselm Busse]

Hey everyone,

I posted this patch almost a month ago and got no reaction. Is there anything 
else I have to/can do to get this fix merged? I’m a little bit worried that it 
gets lost.

- Anselm

> Am 21.07.2021 um 20:00 schrieb Anselm Busse :
> 
> This commit fixes the bug as report in https://trac.ffmpeg.org/ticket/9231 by 
> removing the line that overwrites the user settings for max_b_frames.
> 
> Signed-off-by: Anselm Busse 
> ---
> libavcodec/videotoolboxenc.c | 1 -
> 1 file changed, 1 deletion(-)
> 
> diff --git a/libavcodec/videotoolboxenc.c b/libavcodec/videotoolboxenc.c
> index 4eaabed5d8..8dfd6e3d0c 100644
> --- a/libavcodec/videotoolboxenc.c
> +++ b/libavcodec/videotoolboxenc.c
> @@ -1398,7 +1398,6 @@ static int vtenc_configure_encoder(AVCodecContext 
> *avctx)
> }
> 
> vtctx->codec_id = avctx->codec_id;
> -avctx->max_b_frames = 16;
> 
> if (vtctx->codec_id == AV_CODEC_ID_H264) {
> vtctx->get_param_set_func = 
> CMVideoFormatDescriptionGetH264ParameterSetAtIndex;
> -- 
> 2.32.0
> 

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH v2] avutils/hwcontext: When deriving a hwdevice, search for existing device in both directions

[Xiang, Haihao]

On Tue, 2021-08-10 at 09:52 +, Soft Works wrote:
> The test /libavutil/tests/hwdevice checks that when deriving a device
> from a source device and then deriving back to the type of the source
> device, the result is matching the original source device, i.e. the
> derivation mechanism doesn't create a new device in this case.
> 
> Previously, this test was usually passed, but only due to two different
> kind of flaws:
> 
> 1. The test covers only a single level of derivation (and back)
> 
> It derives device Y from device X and then Y back to the type of X and
> checks whether the result matches X.
> 
> What it doesn't check for, are longer chains of derivation like:
> 
> CUDA1 > OpenCL2 > CUDA3 and then back to OpenCL4
> 
> In that case, the second derivation returns the first device (CUDA3 ==
> CUDA1), but when deriving OpenCL4, hwcontext.c was creating a new
> OpenCL4 context instead of returning OpenCL2, because there was no link
> from CUDA1 to OpenCL2 (only backwards from OpenCL2 to CUDA1)
> 
> If the test would check for two levels of derivation, it would have
> failed.
> 
> This patch fixes those (yet untested) cases by introducing forward
> references (derived_device) in addition to the existing back references
> (source_device).
> 
> 2. hwcontext_qsv didn't properly set the source_device
> 
> In case of QSV, hwcontext_qsv creates a source context internally
> (vaapi, dxva2 or d3d11va) without calling av_hwdevice_ctx_create_derived
> and without setting source_device.
> 
> This way, the hwcontext test ran successful, but what practically
> happened, was that - for example - deriving vaapi from qsv didn't return
> the original underlying vaapi device and a new one was created instead:
> Exactly what the test is intended to detect and prevent. It just
> couldn't do so, because the original device was hidden (= not set as the
> source_device of the QSV device).
> 
> This patch properly makes these setting and fixes all derivation
> scenarios.
> 
> (at a later stage, /libavutil/tests/hwdevice should be extended to check
> longer derivation chains as well)
> 

This change causes a regression when running the command below:

$> ffmpeg -y -hwaccel qsv -c:v h264_qsv -i input.h264 -filter_complex
"split[s0][s1]" -map "[s0]" -c:v h264_qsv out0.h264 -map "[s1]" -c:v h264_qsv
out1.h264

...

video:143kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing
overhead: unknown
corrupted size vs. prev_size in fastbins
Aborted

Thanks
Haihao


> Signed-off-by: softworkz 
> ---
> v2: allow storing multiple derived devices in a device ctx; add checks for oom
>  libavutil/hwcontext.c  | 38 ++
>  libavutil/hwcontext.h  |  1 +
>  libavutil/hwcontext_internal.h |  6 ++
>  libavutil/hwcontext_qsv.c  | 10 -
>  4 files changed, 54 insertions(+), 1 deletion(-)
> 
> diff --git a/libavutil/hwcontext.c b/libavutil/hwcontext.c
> index d13d0f7c9b..7f4e541553 100644
> --- a/libavutil/hwcontext.c
> +++ b/libavutil/hwcontext.c
> @@ -122,6 +122,7 @@ static const AVClass hwdevice_ctx_class = {
>  static void hwdevice_ctx_free(void *opaque, uint8_t *data)
>  {
>  AVHWDeviceContext *ctx = (AVHWDeviceContext*)data;
> +int i;
>  
>  /* uninit might still want access the hw context and the user
>   * free() callback might destroy it, so uninit has to be called first */
> @@ -132,6 +133,8 @@ static void hwdevice_ctx_free(void *opaque, uint8_t *data)
>  ctx->free(ctx);
>  
>  av_buffer_unref(>internal->source_device);
> +for (i = 0; i < AV_HWDEVICE_TYPE_NB; i++)
> +av_buffer_unref(>internal->derived_devices[i]);
>  
>  av_freep(>hwctx);
>  av_freep(>internal->priv);
> @@ -643,6 +646,26 @@ fail:
>  return ret;
>  }
>  
> +static AVBufferRef* find_derived_hwdevice_ctx(AVBufferRef *src_ref, enum
> AVHWDeviceType type)
> +{
> +AVBufferRef *tmp_ref;
> +AVHWDeviceContext *src_ctx;
> +int i;
> +
> +src_ctx = (AVHWDeviceContext*)src_ref->data;
> +if (src_ctx->type == type)
> +return src_ref;
> +
> +for (i = 0; i < AV_HWDEVICE_TYPE_NB; i++)
> +if (src_ctx->internal->derived_devices[i]) {
> +tmp_ref = find_derived_hwdevice_ctx(src_ctx->internal-
> >derived_devices[i], type);
> +if (tmp_ref)
> +return tmp_ref;
> +}
> +
> +return 0;
> +}
> +
>  int av_hwdevice_ctx_create_derived_opts(AVBufferRef **dst_ref_ptr,
>  enum AVHWDeviceType type,
>  AVBufferRef *src_ref,
> @@ -666,6 +689,16 @@ int av_hwdevice_ctx_create_derived_opts(AVBufferRef
> **dst_ref_ptr,
>  tmp_ref = tmp_ctx->internal->source_device;
>  }
>  
> +tmp_ref = find_derived_hwdevice_ctx(src_ref, type);
> +if (tmp_ref) {
> +dst_ref = av_buffer_ref(tmp_ref);
> +if (!dst_ref) {
> +ret = AVERROR(ENOMEM);
> +goto fail;
> +}
> +

Re: [FFmpeg-devel] [RFC] Suggestion for a Nicer Integration with GitHub

[Steven Liu]

> 2021年8月13日 下午1:12，Soft Works  写道：
> 
> 
>> -Original Message-
>> From: ffmpeg-devel  On Behalf Of
>> Steven Liu
>> Sent: Friday, 13 August 2021 05:01
>> To: FFmpeg development discussions and patches > de...@ffmpeg.org>
>> Cc: Steven Liu 
>> Subject: Re: [FFmpeg-devel] [RFC] Suggestion for a Nicer Integration
>> with GitHub
>> 
>> 
>> Hi All,
>> 
>>  I think the people who want contribute patches to ffmpeg, they
>> can use any tools, whatever mail or GitHub.
>>  If the developer want submit patches to ffmpeg, of cause if
>> the develop have intrested in ffmpeg, he can find the way in
>> documents.
> 
> There's a misunderstanding:
> 
> This is not about developers being incapable to work with the 
> mailing list. 
> 
> It's about developers being unwilling to participate due to 
> the outdated and inferior (from their pov) tooling.
All developers and users too, and there have GitHub mirror now.
If users/whatever people really want talk with ffmpeg, they will read documents 
and use mail list too, look at Linux Kernel Community.
Whatever tools, but I cannot agree that you said it’s outdated now we are using.

> 
> Sw
> 
>> 
>> ___
>> 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".
> 

Thanks

Steven Liu



___
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".