Re: [FFmpeg-devel] [PATCH] avcodec/hevc_cabac: cabac_init_state, do not use magic number which not listed on the spec

[Carl Eugen Hoyos]

Am So., 21. März 2021 um 06:13 Uhr schrieb Nuo Mi :
>
> Magic number 124 and ^= are not listed on the spec.
> Strictly following the spec will make a reader's life much easier. See (9-6) 
> for details

But FFmpeg is not providing a reference application for the reader,
this is software actually used by real people (both as a library in
other projects and in the ffmpeg application).

Afaict, the question is if the hevc cabac reader is faster or slower
with your patch.
It looks to me as if you are replacing one condition with two conditions.

Carl Eugen
___
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/aom: Force default qmax to 0 if crf was set to 0

[Carl Eugen Hoyos]

Am So., 21. März 2021 um 02:04 Uhr schrieb James Almer :
>
> On 3/20/2021 3:30 PM, Carl Eugen Hoyos wrote:
> > Am Sa., 20. März 2021 um 19:06 Uhr schrieb James Almer :
> >>
> >> On 3/20/2021 2:51 PM, Carl Eugen Hoyos wrote:
> >>> Hi!
> >>>
> >>> Attached patch fixes lossless aom encoding in some cases for me, it is
> >>> still possible to force lossy encoding with crf == 0 and qmax > 0.
> >>>
> >>> Please comment, Carl Eugen
> >>
> >>
> >>>  From a7b9b60d7091bbf0af84b8eda8bc84ce858d071e Mon Sep 17 00:00:00 2001
> >>> From: Carl Eugen Hoyos 
> >>> Date: Sat, 20 Mar 2021 18:47:52 +0100
> >>> Subject: [PATCH] lavc/aom: Force default qmax to 0 if crf was set to 0.
> >>
> >> libaomenc, not just "aom".
> >
> > I hope "aomenc" is ok.
> >
> > New patch attached.
> >
> > Thank you for the review, Carl Eugen
>
> Should be ok.

Pushed.

Thank you, Carl Eugen
___
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] Guided Filter Project | GSoC 2021

[Piyush Chauhan]

Hello Steven,

Eagerly waiting for your reply.

Piyush

On Sat, 20 Mar 2021 at 02:20, Piyush Chauhan 
wrote:

> 15 Mar 2021, 07:14, Steven Liu :
>
> Hi Piyushi Chanuhan,
>>
>> 1st. You could try understand these rules under the link:
>> https://summerofcode.withgoogle.com/get-started/
>>
>> 2nd. And understand Guided Filter Calculation:
>> For example: http://kaiminghe.com/eccv10/
>>
>> 3rd. And try to implement a filter for that.
>
>
> Hello Steven,
>
> I have implemented the code for the Guided filter and read the
> contribution guides
> https://ffmpeg.org/developer.html
> https://ffmpeg.org/git-howto.html
> Can you guide me with the next steps? And should I submit a patch?
>
> Thanks & Regards,
> Piyush Chauhan
>
> On Mon, 15 Mar 2021 at 10:50, Piyush Chauhan 
> wrote:
>
>> Hello Steven,
>> Thanks for the instructions.
>> I'm done with the first two-step and currently working on the
>> implementation.
>> I'll get back to you once it's finished.
>>
>> Thanks
>>
>> Piyush Chauhan
>>
>> On Mon, 15 Mar 2021 at 07:14, Steven Liu  wrote:
>>
>>>
>>>
>>> > 2021年3月15日 上午5:36，Piyush Chauhan  写道：
>>> >
>>> > Hello Everyone,
>>> > First: Thank You so much for making this awesome tool.
>>> > Second: My name is Piyush Chauhan, I'm a computer science,
>>> Undergraduate
>>> > student, from India.
>>> > Found this project really interesting and coinciding with my skill
>>> sets.
>>> > I've started grokking through the codebase, read the guided filter
>>> >  research
>>> paper(i
>>> > had to google to understand some of the stuff), and read all the
>>> > contribution instructions.
>>> > Now, I'm working on the patch for the qualification task.
>>> > Please let me know if there is a conflict.
>>> > Looking forward to working with you all.
>>>
>>> Hi Piyushi Chanuhan,
>>>
>>> 1st. You could try understand these rules under the link:
>>> https://summerofcode.withgoogle.com/get-started/
>>>
>>> 2nd. And understand Guided Filter Calculation:
>>> For example: http://kaiminghe.com/eccv10/
>>>
>>> 3rd. And try to implement a filter for that.
>>>
>>> >
>>> > Thanks & Regards,
>>> > Piyush (mugen on the ffmpeg-devel channel)
>>> > ___
>>> > 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".
>>
>>
___
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] Guided Filter Project | GSoC 2021

[Steven Liu]

> 2021年3月21日 下午5:27，Piyush Chauhan  写道：
> 
> Hello Steven,
> 
> Eagerly waiting for your reply.
You looks rush to finish this project and finish it, but I think we should in 
the timeline of GSoC.
And there have rule of GSoC, but I cannot sure you have read all of the content 
which I leaved. 
I think if will not so rush to finish this project if you really read that.

> 
> 
> Piyush
> 
> On Sat, 20 Mar 2021 at 02:20, Piyush Chauhan  
> wrote:
> 15 Mar 2021, 07:14, Steven Liu :
> Hi Piyushi Chanuhan,
> 
> 1st. You could try understand these rules under the link:
> https://summerofcode.withgoogle.com/get-started/
> 
> 2nd. And understand Guided Filter Calculation:
> For example: http://kaiminghe.com/eccv10/
> 
> 3rd. And try to implement a filter for that.
> 
> Hello Steven,
> 
> I have implemented the code for the Guided filter and read the contribution 
> guides 
> https://ffmpeg.org/developer.html
> https://ffmpeg.org/git-howto.html 
> Can you guide me with the next steps? And should I submit a patch?
> 
> Thanks & Regards,
> Piyush Chauhan
> 
> On Mon, 15 Mar 2021 at 10:50, Piyush Chauhan  
> wrote:
> Hello Steven, 
> Thanks for the instructions.
> I'm done with the first two-step and currently working on the implementation.
> I'll get back to you once it's finished.
> 
> Thanks
> 
> Piyush Chauhan
> 
> On Mon, 15 Mar 2021 at 07:14, Steven Liu  wrote:
> 
> 
> > 2021年3月15日 上午5:36，Piyush Chauhan  写道：
> > 
> > Hello Everyone,
> > First: Thank You so much for making this awesome tool.
> > Second: My name is Piyush Chauhan, I'm a computer science, Undergraduate
> > student, from India.
> > Found this project really interesting and coinciding with my skill sets.
> > I've started grokking through the codebase, read the guided filter
> >  research paper(i
> > had to google to understand some of the stuff), and read all the
> > contribution instructions.
> > Now, I'm working on the patch for the qualification task.
> > Please let me know if there is a conflict.
> > Looking forward to working with you all.
> 
> Hi Piyushi Chanuhan,
> 
> 1st. You could try understand these rules under the link:
> https://summerofcode.withgoogle.com/get-started/
> 
> 2nd. And understand Guided Filter Calculation:
> For example: http://kaiminghe.com/eccv10/
> 
> 3rd. And try to implement a filter for that.
> 
> > 
> > Thanks & Regards,
> > Piyush (mugen on the ffmpeg-devel channel)
> > ___
> > 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".

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

Re: [FFmpeg-devel] [PATCH] vf_v360: fix (i)flat_range for fisheye projection

[Paul B Mahol]

Please make log message consistent with other commits to this file.

Also make set of patches to be applied all at once instead each single one.

On Fri, Mar 19, 2021 at 1:08 PM Daniel Playfair Cal <
daniel.playfair@gmail.com> wrote:

> This changes the iflat_range and flat_range values for the fisheye
> projection so that they indicate the maximum angle between an observed
> point and the center (direction the camera is facing). This matches the
> meaning of those variables in the flat projection.
>
> Signed-off-by: Daniel Playfair Cal 
> ---
>
> Sorry for the previous identical patch, this version really does remove
> the use of double literals.
>
>  libavfilter/vf_v360.c | 19 +--
>  1 file changed, 9 insertions(+), 10 deletions(-)
>
> diff --git a/libavfilter/vf_v360.c b/libavfilter/vf_v360.c
> index 94473cd5b3..7535612d34 100644
> --- a/libavfilter/vf_v360.c
> +++ b/libavfilter/vf_v360.c
> @@ -2807,9 +2807,8 @@ static int prepare_fisheye_out(AVFilterContext *ctx)
>  {
>  V360Context *s = ctx->priv;
>
> -s->flat_range[0] = s->h_fov / 180.f;
> -s->flat_range[1] = s->v_fov / 180.f;
> -
> +s->flat_range[0] = 0.5f * s->h_fov * M_PI / 180.f;
> +s->flat_range[1] = 0.5f * s->v_fov * M_PI / 180.f;
>  return 0;
>  }
>
> @@ -2827,8 +2826,8 @@ static int fisheye_to_xyz(const V360Context *s,
>int i, int j, int width, int height,
>float *vec)
>  {
> -const float uf = s->flat_range[0] * ((2.f * i) / width  - 1.f);
> -const float vf = s->flat_range[1] * ((2.f * j + 1.f) / height - 1.f);
> +const float uf = 2.f * s->flat_range[0] / M_PI * ((2.f * i) / width
> - 1.f);
> +const float vf = 2.f * s->flat_range[1] / M_PI * ((2.f * j + 1.f) /
> height - 1.f);
>
>  const float phi   = atan2f(vf, uf);
>  const float theta = M_PI_2 * (1.f - hypotf(uf, vf));
> @@ -2858,8 +2857,8 @@ static int prepare_fisheye_in(AVFilterContext *ctx)
>  {
>  V360Context *s = ctx->priv;
>
> -s->iflat_range[0] = s->ih_fov / 180.f;
> -s->iflat_range[1] = s->iv_fov / 180.f;
> +s->iflat_range[0] = 0.5f * s->ih_fov * M_PI / 180.f;
> +s->iflat_range[1] = 0.5f * s->iv_fov * M_PI / 180.f;
>
>  return 0;
>  }
> @@ -2882,10 +2881,10 @@ static int xyz_to_fisheye(const V360Context *s,
>  {
>  const float h   = hypotf(vec[0], vec[1]);
>  const float lh  = h > 0.f ? h : 1.f;
> -const float phi = atan2f(h, vec[2]) / M_PI;
> +const float phi = atan2f(h, vec[2]);
>
> -float uf = vec[0] / lh * phi / s->iflat_range[0];
> -float vf = vec[1] / lh * phi / s->iflat_range[1];
> +float uf = 0.5f * vec[0] / lh * phi / s->iflat_range[0];
> +float vf = 0.5f * vec[1] / lh * phi / s->iflat_range[1];
>
>  const int visible = hypotf(uf, vf) <= 0.5f;
>  int ui, vi;
> --
> 2.31.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] Guided Filter Project | GSoC 2021

[Paul B Mahol]

On Sun, Mar 21, 2021 at 10:35 AM Steven Liu  wrote:

>
>
> > 2021年3月21日 下午5:27，Piyush Chauhan  写道：
> >
> > Hello Steven,
> >
> > Eagerly waiting for your reply.
> You looks rush to finish this project and finish it, but I think we should
> in the timeline of GSoC.
> And there have rule of GSoC, but I cannot sure you have read all of the
> content which I leaved.
> I think if will not so rush to finish this project if you really read that.
>

I so nowhere rushed code :) ..


>
> >
> >
> > Piyush
> >
> > On Sat, 20 Mar 2021 at 02:20, Piyush Chauhan <
> piyushchauhan1...@gmail.com> wrote:
> > 15 Mar 2021, 07:14, Steven Liu :
> > Hi Piyushi Chanuhan,
> >
> > 1st. You could try understand these rules under the link:
> > https://summerofcode.withgoogle.com/get-started/
> >
> > 2nd. And understand Guided Filter Calculation:
> > For example: http://kaiminghe.com/eccv10/
> >
> > 3rd. And try to implement a filter for that.
> >
> > Hello Steven,
> >
> > I have implemented the code for the Guided filter and read the
> contribution guides
> > https://ffmpeg.org/developer.html
> > https://ffmpeg.org/git-howto.html
> > Can you guide me with the next steps? And should I submit a patch?
> >
> > Thanks & Regards,
> > Piyush Chauhan
> >
> > On Mon, 15 Mar 2021 at 10:50, Piyush Chauhan <
> piyushchauhan1...@gmail.com> wrote:
> > Hello Steven,
> > Thanks for the instructions.
> > I'm done with the first two-step and currently working on the
> implementation.
> > I'll get back to you once it's finished.
> >
> > Thanks
> >
> > Piyush Chauhan
> >
> > On Mon, 15 Mar 2021 at 07:14, Steven Liu  wrote:
> >
> >
> > > 2021年3月15日 上午5:36，Piyush Chauhan  写道：
> > >
> > > Hello Everyone,
> > > First: Thank You so much for making this awesome tool.
> > > Second: My name is Piyush Chauhan, I'm a computer science,
> Undergraduate
> > > student, from India.
> > > Found this project really interesting and coinciding with my skill
> sets.
> > > I've started grokking through the codebase, read the guided filter
> > >  research
> paper(i
> > > had to google to understand some of the stuff), and read all the
> > > contribution instructions.
> > > Now, I'm working on the patch for the qualification task.
> > > Please let me know if there is a conflict.
> > > Looking forward to working with you all.
> >
> > Hi Piyushi Chanuhan,
> >
> > 1st. You could try understand these rules under the link:
> > https://summerofcode.withgoogle.com/get-started/
> >
> > 2nd. And understand Guided Filter Calculation:
> > For example: http://kaiminghe.com/eccv10/
> >
> > 3rd. And try to implement a filter for that.
> >
> > >
> > > Thanks & Regards,
> > > Piyush (mugen on the ffmpeg-devel channel)
> > > ___
> > > 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".
>
> 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".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

[FFmpeg-devel] [PATCH 1/5] avcodec/avcodec: Use dedicated pointer to access AVCodecInternal

[Andreas Rheinhardt]

Signed-off-by: Andreas Rheinhardt 
---
 libavcodec/avcodec.c | 48 +++-
 1 file changed, 25 insertions(+), 23 deletions(-)

diff --git a/libavcodec/avcodec.c b/libavcodec/avcodec.c
index 2f3896dcc4..3088d2ff3f 100644
--- a/libavcodec/avcodec.c
+++ b/libavcodec/avcodec.c
@@ -527,45 +527,47 @@ av_cold int avcodec_close(AVCodecContext *avctx)
 return 0;
 
 if (avcodec_is_open(avctx)) {
+AVCodecInternal *avci = avctx->internal;
+
 if (CONFIG_FRAME_THREAD_ENCODER &&
-avctx->internal->frame_thread_encoder && avctx->thread_count > 1) {
+avci->frame_thread_encoder && avctx->thread_count > 1) {
 ff_frame_thread_encoder_free(avctx);
 }
-if (HAVE_THREADS && avctx->internal->thread_ctx)
+if (HAVE_THREADS && avci->thread_ctx)
 ff_thread_free(avctx);
 if (avctx->codec && avctx->codec->close)
 avctx->codec->close(avctx);
-avctx->internal->byte_buffer_size = 0;
-av_freep(&avctx->internal->byte_buffer);
+avci->byte_buffer_size = 0;
+av_freep(&avci->byte_buffer);
 #if FF_API_OLD_ENCDEC
-av_frame_free(&avctx->internal->to_free);
-av_frame_free(&avctx->internal->compat_decode_frame);
-av_packet_free(&avctx->internal->compat_encode_packet);
+av_frame_free(&avci->to_free);
+av_frame_free(&avci->compat_decode_frame);
+av_packet_free(&avci->compat_encode_packet);
 #endif
-av_frame_free(&avctx->internal->buffer_frame);
-av_packet_free(&avctx->internal->buffer_pkt);
-av_packet_unref(avctx->internal->last_pkt_props);
-while (av_fifo_size(avctx->internal->pkt_props) >=
-   sizeof(*avctx->internal->last_pkt_props)) {
-av_fifo_generic_read(avctx->internal->pkt_props,
- avctx->internal->last_pkt_props,
- sizeof(*avctx->internal->last_pkt_props),
+av_frame_free(&avci->buffer_frame);
+av_packet_free(&avci->buffer_pkt);
+av_packet_unref(avci->last_pkt_props);
+while (av_fifo_size(avci->pkt_props) >=
+   sizeof(*avci->last_pkt_props)) {
+av_fifo_generic_read(avci->pkt_props,
+ avci->last_pkt_props,
+ sizeof(*avci->last_pkt_props),
  NULL);
-av_packet_unref(avctx->internal->last_pkt_props);
+av_packet_unref(avci->last_pkt_props);
 }
-av_packet_free(&avctx->internal->last_pkt_props);
-av_fifo_freep(&avctx->internal->pkt_props);
+av_packet_free(&avci->last_pkt_props);
+av_fifo_freep(&avci->pkt_props);
 
-av_packet_free(&avctx->internal->ds.in_pkt);
-av_frame_free(&avctx->internal->es.in_frame);
+av_packet_free(&avci->ds.in_pkt);
+av_frame_free(&avci->es.in_frame);
 
-av_buffer_unref(&avctx->internal->pool);
+av_buffer_unref(&avci->pool);
 
 if (avctx->hwaccel && avctx->hwaccel->uninit)
 avctx->hwaccel->uninit(avctx);
-av_freep(&avctx->internal->hwaccel_priv_data);
+av_freep(&avci->hwaccel_priv_data);
 
-av_bsf_free(&avctx->internal->bsf);
+av_bsf_free(&avci->bsf);
 
 av_freep(&avctx->internal);
 }
-- 
2.27.0

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

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

[FFmpeg-devel] [PATCH 2/5] avcodec/avcodec: Don't use NULL for %s printf specifier

[Andreas Rheinhardt]

Our "get name" functions can return NULL for invalid/unknown
arguments. So check for this.

Signed-off-by: Andreas Rheinhardt 
---
av_get_colorspace_name() can even return NULL for supported colorspaces.

 libavcodec/avcodec.c | 33 +
 1 file changed, 17 insertions(+), 16 deletions(-)

diff --git a/libavcodec/avcodec.c b/libavcodec/avcodec.c
index 3088d2ff3f..93383dc9fb 100644
--- a/libavcodec/avcodec.c
+++ b/libavcodec/avcodec.c
@@ -607,6 +607,7 @@ void avcodec_string(char *buf, int buf_size, AVCodecContext 
*enc, int encode)
 int new_line = 0;
 AVRational display_aspect_ratio;
 const char *separator = enc->dump_separator ? (const char 
*)enc->dump_separator : ", ";
+const char *str;
 
 if (!buf || buf_size <= 0)
 return;
@@ -642,14 +643,14 @@ void avcodec_string(char *buf, int buf_size, 
AVCodecContext *enc, int encode)
 av_strlcat(buf, separator, buf_size);
 
 snprintf(buf + strlen(buf), buf_size - strlen(buf),
- "%s", enc->pix_fmt == AV_PIX_FMT_NONE ? "none" :
- av_get_pix_fmt_name(enc->pix_fmt));
+ "%s", enc->pix_fmt == AV_PIX_FMT_NONE ? "none" :
+ av_x_if_null(av_get_pix_fmt_name(enc->pix_fmt), 
"unknown"));
 if (enc->bits_per_raw_sample && enc->pix_fmt != AV_PIX_FMT_NONE &&
 enc->bits_per_raw_sample < 
av_pix_fmt_desc_get(enc->pix_fmt)->comp[0].depth)
 av_strlcatf(detail, sizeof(detail), "%d bpc, ", 
enc->bits_per_raw_sample);
-if (enc->color_range != AVCOL_RANGE_UNSPECIFIED)
-av_strlcatf(detail, sizeof(detail), "%s, ",
-av_color_range_name(enc->color_range));
+if (enc->color_range != AVCOL_RANGE_UNSPECIFIED &&
+(str = av_color_range_name(enc->color_range)))
+av_strlcatf(detail, sizeof(detail), "%s, ", str);
 
 if (enc->colorspace != AVCOL_SPC_UNSPECIFIED ||
 enc->color_primaries != AVCOL_PRI_UNSPECIFIED ||
@@ -658,12 +659,11 @@ void avcodec_string(char *buf, int buf_size, 
AVCodecContext *enc, int encode)
 enc->colorspace != (int)enc->color_trc) {
 new_line = 1;
 av_strlcatf(detail, sizeof(detail), "%s/%s/%s, ",
-av_color_space_name(enc->colorspace),
-av_color_primaries_name(enc->color_primaries),
-av_color_transfer_name(enc->color_trc));
-} else
-av_strlcatf(detail, sizeof(detail), "%s, ",
-av_get_colorspace_name(enc->colorspace));
+
av_x_if_null(av_color_space_name(enc->colorspace), "unknown"),
+
av_x_if_null(av_color_primaries_name(enc->color_primaries), "unknown"),
+
av_x_if_null(av_color_transfer_name(enc->color_trc), "unkown"));
+ } else if (str = av_get_colorspace_name(enc->colorspace))
+   av_strlcatf(detail, sizeof(detail), "%s, ", str);
 }
 
 if (enc->field_order != AV_FIELD_UNKNOWN) {
@@ -681,9 +681,9 @@ void avcodec_string(char *buf, int buf_size, AVCodecContext 
*enc, int encode)
 }
 
 if (av_log_get_level() >= AV_LOG_VERBOSE &&
-enc->chroma_sample_location != AVCHROMA_LOC_UNSPECIFIED)
-av_strlcatf(detail, sizeof(detail), "%s, ",
-
av_chroma_location_name(enc->chroma_sample_location));
+enc->chroma_sample_location != AVCHROMA_LOC_UNSPECIFIED &&
+(str = av_chroma_location_name(enc->chroma_sample_location)))
+av_strlcatf(detail, sizeof(detail), "%s, ", str);
 
 if (strlen(detail) > 1) {
 detail[strlen(detail) - 2] = 0;
@@ -741,9 +741,10 @@ void avcodec_string(char *buf, int buf_size, 
AVCodecContext *enc, int encode)
  "%d Hz, ", enc->sample_rate);
 }
 av_get_channel_layout_string(buf + strlen(buf), buf_size - 
strlen(buf), enc->channels, enc->channel_layout);
-if (enc->sample_fmt != AV_SAMPLE_FMT_NONE) {
+if (enc->sample_fmt != AV_SAMPLE_FMT_NONE &&
+(str = av_get_sample_fmt_name(enc->sample_fmt))) {
 snprintf(buf + strlen(buf), buf_size - strlen(buf),
- ", %s", av_get_sample_fmt_name(enc->sample_fmt));
+ ", %s", str);
 }
 if (   enc->bits_per_raw_sample > 0
 && enc->bits_per_raw_sample != 
av_get_bytes_per_sample(enc->sample_fmt) * 8)
-- 
2.27.0

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

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

[FFmpeg-devel] [PATCH 3/5] avcodec/avcodec: Update check for identical colorspace/primaries/trc names

[Andreas Rheinhardt]

If the numerical constants for colorspace, transfer characteristics
and color primaries coincide, the current code presumes the
corresponding names to be identical and prints only one of them obtained
via av_get_colorspace_name(). There are two issues with this: The first
is that the underlying assumption is wrong: The names only coincide in
the 0-7 range, they differ for more recent additions. The second is that
av_get_colorspace_name() is outdated itself; it has not been updated
with the names of the newly defined colorspaces.

Fix both of this by using the names from
av_color_(space|primaries|transfer)_name() and comparing them via
strcmp; don't use av_get_colorspace_name() at all.

Signed-off-by: Andreas Rheinhardt 
---
This was our last internal user of av_get_colorspace_name().

 libavcodec/avcodec.c | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/libavcodec/avcodec.c b/libavcodec/avcodec.c
index 93383dc9fb..68a3179b07 100644
--- a/libavcodec/avcodec.c
+++ b/libavcodec/avcodec.c
@@ -655,15 +655,15 @@ void avcodec_string(char *buf, int buf_size, 
AVCodecContext *enc, int encode)
 if (enc->colorspace != AVCOL_SPC_UNSPECIFIED ||
 enc->color_primaries != AVCOL_PRI_UNSPECIFIED ||
 enc->color_trc != AVCOL_TRC_UNSPECIFIED) {
-if (enc->colorspace != (int)enc->color_primaries ||
-enc->colorspace != (int)enc->color_trc) {
+const char *col = 
av_x_if_null(av_color_space_name(enc->colorspace), "unknown");
+const char *pri = 
av_x_if_null(av_color_primaries_name(enc->color_primaries), "unknown");
+const char *trc = 
av_x_if_null(av_color_transfer_name(enc->color_trc), "unkown");
+if (strcmp(col, pri) || strcmp(col, trc)) {
 new_line = 1;
 av_strlcatf(detail, sizeof(detail), "%s/%s/%s, ",
-
av_x_if_null(av_color_space_name(enc->colorspace), "unknown"),
-
av_x_if_null(av_color_primaries_name(enc->color_primaries), "unknown"),
-
av_x_if_null(av_color_transfer_name(enc->color_trc), "unkown"));
- } else if (str = av_get_colorspace_name(enc->colorspace))
-   av_strlcatf(detail, sizeof(detail), "%s, ", str);
+col, pri, trc);
+} else
+av_strlcatf(detail, sizeof(detail), "%s, ", col);
 }
 
 if (enc->field_order != AV_FIELD_UNKNOWN) {
-- 
2.27.0

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

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

[FFmpeg-devel] [PATCH 4/5] avcodec/avcodec: Use AVBPrint in avcodec_string()

[Andreas Rheinhardt]

It automatically records the current length of the string,
whereas the current code contains lots of instances of
snprintf(buf + strlen(buf), buf_size - strlen(buf), ...).

Signed-off-by: Andreas Rheinhardt 
---
 libavcodec/avcodec.c | 133 +--
 1 file changed, 65 insertions(+), 68 deletions(-)

diff --git a/libavcodec/avcodec.c b/libavcodec/avcodec.c
index 68a3179b07..20a237b086 100644
--- a/libavcodec/avcodec.c
+++ b/libavcodec/avcodec.c
@@ -26,6 +26,7 @@
 #include "config.h"
 #include "libavutil/avassert.h"
 #include "libavutil/avstring.h"
+#include "libavutil/bprint.h"
 #include "libavutil/imgutils.h"
 #include "libavutil/mem.h"
 #include "libavutil/opt.h"
@@ -603,6 +604,7 @@ void avcodec_string(char *buf, int buf_size, AVCodecContext 
*enc, int encode)
 const char *codec_type;
 const char *codec_name;
 const char *profile = NULL;
+AVBPrint bprint;
 int64_t bitrate;
 int new_line = 0;
 AVRational display_aspect_ratio;
@@ -611,46 +613,54 @@ void avcodec_string(char *buf, int buf_size, 
AVCodecContext *enc, int encode)
 
 if (!buf || buf_size <= 0)
 return;
+av_bprint_init_for_buffer(&bprint, buf, buf_size);
 codec_type = av_get_media_type_string(enc->codec_type);
 codec_name = avcodec_get_name(enc->codec_id);
 profile = avcodec_profile_name(enc->codec_id, enc->profile);
 
-snprintf(buf, buf_size, "%s: %s", codec_type ? codec_type : "unknown",
- codec_name);
+av_bprintf(&bprint, "%s: %s", codec_type ? codec_type : "unknown",
+   codec_name);
 buf[0] ^= 'a' ^ 'A'; /* first letter in uppercase */
 
 if (enc->codec && strcmp(enc->codec->name, codec_name))
-snprintf(buf + strlen(buf), buf_size - strlen(buf), " (%s)", 
enc->codec->name);
+av_bprintf(&bprint, " (%s)", enc->codec->name);
 
 if (profile)
-snprintf(buf + strlen(buf), buf_size - strlen(buf), " (%s)", profile);
+av_bprintf(&bprint, " (%s)", profile);
 if (   enc->codec_type == AVMEDIA_TYPE_VIDEO
 && av_log_get_level() >= AV_LOG_VERBOSE
 && enc->refs)
-snprintf(buf + strlen(buf), buf_size - strlen(buf),
- ", %d reference frame%s",
- enc->refs, enc->refs > 1 ? "s" : "");
+av_bprintf(&bprint, ", %d reference frame%s",
+   enc->refs, enc->refs > 1 ? "s" : "");
 
 if (enc->codec_tag)
-snprintf(buf + strlen(buf), buf_size - strlen(buf), " (%s / 0x%04X)",
- av_fourcc2str(enc->codec_tag), enc->codec_tag);
+av_bprintf(&bprint, " (%s / 0x%04X)",
+   av_fourcc2str(enc->codec_tag), enc->codec_tag);
 
 switch (enc->codec_type) {
 case AVMEDIA_TYPE_VIDEO:
 {
-char detail[256] = "(";
+unsigned len;
 
-av_strlcat(buf, separator, buf_size);
+av_bprintf(&bprint, "%s%s", separator,
+   enc->pix_fmt == AV_PIX_FMT_NONE ? "none" :
+   av_x_if_null(av_get_pix_fmt_name(enc->pix_fmt), 
"unknown"));
+
+av_bprint_chars(&bprint, '(', 1);
+len = bprint.len;
+
+/* The following check ensures that '(' has been written
+ * and therefore allows us to erase it if it turns out
+ * to be unnecessary. */
+if (!av_bprint_is_complete(&bprint))
+return;
 
-snprintf(buf + strlen(buf), buf_size - strlen(buf),
- "%s", enc->pix_fmt == AV_PIX_FMT_NONE ? "none" :
- av_x_if_null(av_get_pix_fmt_name(enc->pix_fmt), 
"unknown"));
 if (enc->bits_per_raw_sample && enc->pix_fmt != AV_PIX_FMT_NONE &&
 enc->bits_per_raw_sample < 
av_pix_fmt_desc_get(enc->pix_fmt)->comp[0].depth)
-av_strlcatf(detail, sizeof(detail), "%d bpc, ", 
enc->bits_per_raw_sample);
+av_bprintf(&bprint, "%d bpc, ", enc->bits_per_raw_sample);
 if (enc->color_range != AVCOL_RANGE_UNSPECIFIED &&
 (str = av_color_range_name(enc->color_range)))
-av_strlcatf(detail, sizeof(detail), "%s, ", str);
+av_bprintf(&bprint, "%s, ", str);
 
 if (enc->colorspace != AVCOL_SPC_UNSPECIFIED ||
 enc->color_primaries != AVCOL_PRI_UNSPECIFIED ||
@@ -660,10 +670,9 @@ void avcodec_string(char *buf, int buf_size, 
AVCodecContext *enc, int encode)
 const char *trc = 
av_x_if_null(av_color_transfer_name(enc->color_trc), "unkown");
 if (strcmp(col, pri) || strcmp(col, trc)) {
 new_line = 1;
-av_strlcatf(detail, sizeof(detail), "%s/%s/%s, ",
-col, pri, trc);
+av_bprintf(&bprint, "%s/%s/%s, ", col, pri, trc);
 } else
-av_strlcatf(detail, sizeof(detail), "%s, ", col);
+av_bprintf(&bprint, "%s, ", col

[FFmpeg-devel] [PATCH 5/5] avutil/frame: Deprecate av_get_colorspace_name()

[Andreas Rheinhardt]

Contrary to av_color_space_name() it doesn't even support newer
colorspaces.

Signed-off-by: Andreas Rheinhardt 
---
 doc/APIchanges  | 4 
 libavutil/frame.c   | 3 ++-
 libavutil/frame.h   | 5 -
 libavutil/version.h | 5 -
 4 files changed, 14 insertions(+), 3 deletions(-)

diff --git a/doc/APIchanges b/doc/APIchanges
index c928887f79..b41dadee8d 100644
--- a/doc/APIchanges
+++ b/doc/APIchanges
@@ -15,6 +15,10 @@ libavutil: 2017-10-21
 
 API changes, most recent first:
 
+2021-03-21 - xx - lavu 56.72.100 - frame.h
+  Deprecated av_get_colorspace_name().
+  Use av_color_space_name() instead.
+
  8< - FFmpeg 4.4 was cut here  8< -
 
 2021-03-19 - e8c0bca6bd - lavu 56.69.100 - adler32.h
diff --git a/libavutil/frame.c b/libavutil/frame.c
index 75e347bf2f..31a2117b82 100644
--- a/libavutil/frame.c
+++ b/libavutil/frame.c
@@ -120,6 +120,7 @@ FF_ENABLE_DEPRECATION_WARNINGS
 }
 #endif
 
+#if FF_API_COLORSPACE_NAME
 const char *av_get_colorspace_name(enum AVColorSpace val)
 {
 static const char * const name[] = {
@@ -135,7 +136,7 @@ const char *av_get_colorspace_name(enum AVColorSpace val)
 return NULL;
 return name[val];
 }
-
+#endif
 static void get_frame_defaults(AVFrame *frame)
 {
 if (frame->extended_data != frame->data)
diff --git a/libavutil/frame.h b/libavutil/frame.h
index 7d1f8e2935..c24d52d1c6 100644
--- a/libavutil/frame.h
+++ b/libavutil/frame.h
@@ -754,12 +754,15 @@ attribute_deprecated
 voidav_frame_set_color_range(AVFrame *frame, enum AVColorRange val);
 #endif
 
+#if FF_API_COLORSPACE_NAME
 /**
  * Get the name of a colorspace.
  * @return a static string identifying the colorspace; can be NULL.
+ * @deprecated use av_color_space_name
  */
+attribute_deprecated
 const char *av_get_colorspace_name(enum AVColorSpace val);
-
+#endif
 /**
  * Allocate an AVFrame and set its fields to default values.  The resulting
  * struct must be freed using av_frame_free().
diff --git a/libavutil/version.h b/libavutil/version.h
index 55072f8246..e88e1ad08d 100644
--- a/libavutil/version.h
+++ b/libavutil/version.h
@@ -79,7 +79,7 @@
  */
 
 #define LIBAVUTIL_VERSION_MAJOR  56
-#define LIBAVUTIL_VERSION_MINOR  71
+#define LIBAVUTIL_VERSION_MINOR  72
 #define LIBAVUTIL_VERSION_MICRO 100
 
 #define LIBAVUTIL_VERSION_INT   AV_VERSION_INT(LIBAVUTIL_VERSION_MAJOR, \
@@ -141,6 +141,9 @@
 #ifndef FF_API_DECLARE_ALIGNED
 #define FF_API_DECLARE_ALIGNED  (LIBAVUTIL_VERSION_MAJOR < 58)
 #endif
+#ifndef FF_API_COLORSPACE_NAME
+#define FF_API_COLORSPACE_NAME  (LIBAVUTIL_VERSION_MAJOR < 58)
+#endif
 
 /**
  * @}
-- 
2.27.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] Guided Filter Project | GSoC 2021

[Steven Liu]

> 2021年3月21日 下午5:42，Paul B Mahol  写道：
> 
> 
> 
> On Sun, Mar 21, 2021 at 10:35 AM Steven Liu  wrote:
> 
> 
> > 2021年3月21日 下午5:27，Piyush Chauhan  写道：
> > 
> > Hello Steven,
> > 
> > Eagerly waiting for your reply.
> You looks rush to finish this project and finish it, but I think we should in 
> the timeline of GSoC.
> And there have rule of GSoC, but I cannot sure you have read all of the 
> content which I leaved. 
> I think if will not so rush to finish this project if you really read that.
> 
> I so nowhere rushed code :) ..
Yes I think you can, but I guess you are not a student right now :D
>  
> 
> > 
> > 
> > Piyush
> > 
> > On Sat, 20 Mar 2021 at 02:20, Piyush Chauhan  
> > wrote:
> > 15 Mar 2021, 07:14, Steven Liu :
> > Hi Piyushi Chanuhan,
> > 
> > 1st. You could try understand these rules under the link:
> > https://summerofcode.withgoogle.com/get-started/
> > 
> > 2nd. And understand Guided Filter Calculation:
> > For example: http://kaiminghe.com/eccv10/
> > 
> > 3rd. And try to implement a filter for that.
> > 
> > Hello Steven,
> > 
> > I have implemented the code for the Guided filter and read the contribution 
> > guides 
> > https://ffmpeg.org/developer.html
> > https://ffmpeg.org/git-howto.html 
> > Can you guide me with the next steps? And should I submit a patch?
> > 
> > Thanks & Regards,
> > Piyush Chauhan
> > 
> > On Mon, 15 Mar 2021 at 10:50, Piyush Chauhan  
> > wrote:
> > Hello Steven, 
> > Thanks for the instructions.
> > I'm done with the first two-step and currently working on the 
> > implementation.
> > I'll get back to you once it's finished.
> > 
> > Thanks
> > 
> > Piyush Chauhan
> > 
> > On Mon, 15 Mar 2021 at 07:14, Steven Liu  wrote:
> > 
> > 
> > > 2021年3月15日 上午5:36，Piyush Chauhan  写道：
> > > 
> > > Hello Everyone,
> > > First: Thank You so much for making this awesome tool.
> > > Second: My name is Piyush Chauhan, I'm a computer science, Undergraduate
> > > student, from India.
> > > Found this project really interesting and coinciding with my skill sets.
> > > I've started grokking through the codebase, read the guided filter
> > >  research 
> > > paper(i
> > > had to google to understand some of the stuff), and read all the
> > > contribution instructions.
> > > Now, I'm working on the patch for the qualification task.
> > > Please let me know if there is a conflict.
> > > Looking forward to working with you all.
> > 
> > Hi Piyushi Chanuhan,
> > 
> > 1st. You could try understand these rules under the link:
> > https://summerofcode.withgoogle.com/get-started/
> > 
> > 2nd. And understand Guided Filter Calculation:
> > For example: http://kaiminghe.com/eccv10/
> > 
> > 3rd. And try to implement a filter for that.
> > 
> > > 
> > > Thanks & Regards,
> > > Piyush (mugen on the ffmpeg-devel channel)
> > > ___
> > > 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".
> 
> 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".

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

Re: [FFmpeg-devel] Guided Filter Project | GSoC 2021

[Paul B Mahol]

On Sun, Mar 21, 2021 at 10:58 AM Steven Liu  wrote:

>
>
> > 2021年3月21日 下午5:42，Paul B Mahol  写道：
> >
> >
> >
> > On Sun, Mar 21, 2021 at 10:35 AM Steven Liu  wrote:
> >
> >
> > > 2021年3月21日 下午5:27，Piyush Chauhan  写道：
> > >
> > > Hello Steven,
> > >
> > > Eagerly waiting for your reply.
> > You looks rush to finish this project and finish it, but I think we
> should in the timeline of GSoC.
> > And there have rule of GSoC, but I cannot sure you have read all of the
> content which I leaved.
> > I think if will not so rush to finish this project if you really read
> that.
> >
> > I so nowhere rushed code :) ..
> Yes I think you can, but I guess you are not a student right now :D
>

Yes, I just though that qualified student should post their qualification
work for review on mailing list first so everything is transparent.


> >
> >
> > >
> > >
> > > Piyush
> > >
> > > On Sat, 20 Mar 2021 at 02:20, Piyush Chauhan <
> piyushchauhan1...@gmail.com> wrote:
> > > 15 Mar 2021, 07:14, Steven Liu :
> > > Hi Piyushi Chanuhan,
> > >
> > > 1st. You could try understand these rules under the link:
> > > https://summerofcode.withgoogle.com/get-started/
> > >
> > > 2nd. And understand Guided Filter Calculation:
> > > For example: http://kaiminghe.com/eccv10/
> > >
> > > 3rd. And try to implement a filter for that.
> > >
> > > Hello Steven,
> > >
> > > I have implemented the code for the Guided filter and read the
> contribution guides
> > > https://ffmpeg.org/developer.html
> > > https://ffmpeg.org/git-howto.html
> > > Can you guide me with the next steps? And should I submit a patch?
> > >
> > > Thanks & Regards,
> > > Piyush Chauhan
> > >
> > > On Mon, 15 Mar 2021 at 10:50, Piyush Chauhan <
> piyushchauhan1...@gmail.com> wrote:
> > > Hello Steven,
> > > Thanks for the instructions.
> > > I'm done with the first two-step and currently working on the
> implementation.
> > > I'll get back to you once it's finished.
> > >
> > > Thanks
> > >
> > > Piyush Chauhan
> > >
> > > On Mon, 15 Mar 2021 at 07:14, Steven Liu  wrote:
> > >
> > >
> > > > 2021年3月15日 上午5:36，Piyush Chauhan  写道：
> > > >
> > > > Hello Everyone,
> > > > First: Thank You so much for making this awesome tool.
> > > > Second: My name is Piyush Chauhan, I'm a computer science,
> Undergraduate
> > > > student, from India.
> > > > Found this project really interesting and coinciding with my skill
> sets.
> > > > I've started grokking through the codebase, read the guided filter
> > > >  research
> paper(i
> > > > had to google to understand some of the stuff), and read all the
> > > > contribution instructions.
> > > > Now, I'm working on the patch for the qualification task.
> > > > Please let me know if there is a conflict.
> > > > Looking forward to working with you all.
> > >
> > > Hi Piyushi Chanuhan,
> > >
> > > 1st. You could try understand these rules under the link:
> > > https://summerofcode.withgoogle.com/get-started/
> > >
> > > 2nd. And understand Guided Filter Calculation:
> > > For example: http://kaiminghe.com/eccv10/
> > >
> > > 3rd. And try to implement a filter for that.
> > >
> > > >
> > > > Thanks & Regards,
> > > > Piyush (mugen on the ffmpeg-devel channel)
> > > > ___
> > > > 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".
> >
> > 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".
>
> 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".

Re: [FFmpeg-devel] Guided Filter Project | GSoC 2021

[Steven Liu]

> 2021年3月21日 下午6:03，Paul B Mahol  写道：
> 
> 
> 
> On Sun, Mar 21, 2021 at 10:58 AM Steven Liu  wrote:
> 
> 
> > 2021年3月21日 下午5:42，Paul B Mahol  写道：
> > 
> > 
> > 
> > On Sun, Mar 21, 2021 at 10:35 AM Steven Liu  wrote:
> > 
> > 
> > > 2021年3月21日 下午5:27，Piyush Chauhan  写道：
> > > 
> > > Hello Steven,
> > > 
> > > Eagerly waiting for your reply.
> > You looks rush to finish this project and finish it, but I think we should 
> > in the timeline of GSoC.
> > And there have rule of GSoC, but I cannot sure you have read all of the 
> > content which I leaved. 
> > I think if will not so rush to finish this project if you really read that.
> > 
> > I so nowhere rushed code :) ..
> Yes I think you can, but I guess you are not a student right now :D
> 
> Yes, I just though that qualified student should post their qualification 
> work for review on mailing list first so everything is transparent.
There have maybe student want do there qualification work of this project, i 
think all of them want sent the code now, but they are focusing on GSoC 
Timeline now.
Of course, I can tell them to send there patches on mailing list if you want 
review at first step.
I think ffmpeg not only need one guided filter code, but also need found a 
contributor to make contributing to ffmpeg long time.

>  
> >  
> > 
> > > 
> > > 
> > > Piyush
> > > 
> > > On Sat, 20 Mar 2021 at 02:20, Piyush Chauhan 
> > >  wrote:
> > > 15 Mar 2021, 07:14, Steven Liu :
> > > Hi Piyushi Chanuhan,
> > > 
> > > 1st. You could try understand these rules under the link:
> > > https://summerofcode.withgoogle.com/get-started/
> > > 
> > > 2nd. And understand Guided Filter Calculation:
> > > For example: http://kaiminghe.com/eccv10/
> > > 
> > > 3rd. And try to implement a filter for that.
> > > 
> > > Hello Steven,
> > > 
> > > I have implemented the code for the Guided filter and read the 
> > > contribution guides 
> > > https://ffmpeg.org/developer.html
> > > https://ffmpeg.org/git-howto.html 
> > > Can you guide me with the next steps? And should I submit a patch?
> > > 
> > > Thanks & Regards,
> > > Piyush Chauhan
> > > 
> > > On Mon, 15 Mar 2021 at 10:50, Piyush Chauhan 
> > >  wrote:
> > > Hello Steven, 
> > > Thanks for the instructions.
> > > I'm done with the first two-step and currently working on the 
> > > implementation.
> > > I'll get back to you once it's finished.
> > > 
> > > Thanks
> > > 
> > > Piyush Chauhan
> > > 
> > > On Mon, 15 Mar 2021 at 07:14, Steven Liu  wrote:
> > > 
> > > 
> > > > 2021年3月15日 上午5:36，Piyush Chauhan  写道：
> > > > 
> > > > Hello Everyone,
> > > > First: Thank You so much for making this awesome tool.
> > > > Second: My name is Piyush Chauhan, I'm a computer science, Undergraduate
> > > > student, from India.
> > > > Found this project really interesting and coinciding with my skill sets.
> > > > I've started grokking through the codebase, read the guided filter
> > > >  research 
> > > > paper(i
> > > > had to google to understand some of the stuff), and read all the
> > > > contribution instructions.
> > > > Now, I'm working on the patch for the qualification task.
> > > > Please let me know if there is a conflict.
> > > > Looking forward to working with you all.
> > > 
> > > Hi Piyushi Chanuhan,
> > > 
> > > 1st. You could try understand these rules under the link:
> > > https://summerofcode.withgoogle.com/get-started/
> > > 
> > > 2nd. And understand Guided Filter Calculation:
> > > For example: http://kaiminghe.com/eccv10/
> > > 
> > > 3rd. And try to implement a filter for that.
> > > 
> > > > 
> > > > Thanks & Regards,
> > > > Piyush (mugen on the ffmpeg-devel channel)
> > > > ___
> > > > 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".
> > 
> > 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".
> 
> Thanks
> 
> Steven Liu
> 
> 
> 

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

Re: [FFmpeg-devel] Guided Filter Project | GSoC 2021

[Paul B Mahol]

On Sun, Mar 21, 2021 at 11:10 AM Steven Liu  wrote:

>
>
> > 2021年3月21日 下午6:03，Paul B Mahol  写道：
> >
> >
> >
> > On Sun, Mar 21, 2021 at 10:58 AM Steven Liu  wrote:
> >
> >
> > > 2021年3月21日 下午5:42，Paul B Mahol  写道：
> > >
> > >
> > >
> > > On Sun, Mar 21, 2021 at 10:35 AM Steven Liu 
> wrote:
> > >
> > >
> > > > 2021年3月21日 下午5:27，Piyush Chauhan  写道：
> > > >
> > > > Hello Steven,
> > > >
> > > > Eagerly waiting for your reply.
> > > You looks rush to finish this project and finish it, but I think we
> should in the timeline of GSoC.
> > > And there have rule of GSoC, but I cannot sure you have read all of
> the content which I leaved.
> > > I think if will not so rush to finish this project if you really read
> that.
> > >
> > > I so nowhere rushed code :) ..
> > Yes I think you can, but I guess you are not a student right now :D
> >
> > Yes, I just though that qualified student should post their
> qualification work for review on mailing list first so everything is
> transparent.
> There have maybe student want do there qualification work of this project,
> i think all of them want sent the code now, but they are focusing on GSoC
> Timeline now.
> Of course, I can tell them to send there patches on mailing list if you
> want review at first step.
> I think ffmpeg not only need one guided filter code, but also need found a
> contributor to make contributing to ffmpeg long time.
>

Yes, totally agree, but that is very hard to get today.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

[FFmpeg-devel] [PATCH 1/2] lavc/pngdec: fix exporting frame metadata after 5663301560

[Anton Khirnov]

Also avoid a potential race with frame threading, where a frame's
metadata could be modified concurrently with that frame being passed to
another thread.

Fixes #8972

Found-by: Andreas Rheinhardt 
---
 libavcodec/pngdec.c | 27 ++-
 1 file changed, 18 insertions(+), 9 deletions(-)

diff --git a/libavcodec/pngdec.c b/libavcodec/pngdec.c
index a5a71ef161..00fabec34c 100644
--- a/libavcodec/pngdec.c
+++ b/libavcodec/pngdec.c
@@ -57,6 +57,8 @@ typedef struct PNGDecContext {
 ThreadFrame last_picture;
 ThreadFrame picture;
 
+AVDictionary *frame_metadata;
+
 enum PNGHeaderState hdr_state;
 enum PNGImageState pic_state;
 int width, height;
@@ -509,8 +511,7 @@ static uint8_t *iso88591_to_utf8(const uint8_t *in, size_t 
size_in)
 return out;
 }
 
-static int decode_text_chunk(PNGDecContext *s, uint32_t length, int compressed,
- AVDictionary **dict)
+static int decode_text_chunk(PNGDecContext *s, uint32_t length, int compressed)
 {
 int ret, method;
 const uint8_t *data= s->gb.buffer;
@@ -552,7 +553,7 @@ static int decode_text_chunk(PNGDecContext *s, uint32_t 
length, int compressed,
 return AVERROR(ENOMEM);
 }
 
-av_dict_set(dict, kw_utf8, txt_utf8,
+av_dict_set(&s->frame_metadata, kw_utf8, txt_utf8,
 AV_DICT_DONT_STRDUP_KEY | AV_DICT_DONT_STRDUP_VAL);
 return 0;
 }
@@ -710,6 +711,8 @@ static int decode_idat_chunk(AVCodecContext *avctx, 
PNGDecContext *s,
 s->bpp += byte_depth;
 }
 
+av_dict_free(&s->frame_metadata);
+
 ff_thread_release_buffer(avctx, &s->picture);
 if ((ret = ff_thread_get_buffer(avctx, &s->picture, 
AV_GET_BUFFER_FLAG_REF)) < 0)
 return ret;
@@ -1182,7 +1185,6 @@ static int decode_frame_common(AVCodecContext *avctx, 
PNGDecContext *s,
AVFrame *p, const AVPacket *avpkt)
 {
 const AVCRC *crc_tab = av_crc_get_table(AV_CRC_32_IEEE_LE);
-AVDictionary **metadatap = NULL;
 uint32_t tag, length;
 int decode_next_dat = 0;
 int i, ret;
@@ -1250,7 +1252,6 @@ static int decode_frame_common(AVCodecContext *avctx, 
PNGDecContext *s,
 }
 }
 
-metadatap = &p->metadata;
 switch (tag) {
 case MKTAG('I', 'H', 'D', 'R'):
 if ((ret = decode_ihdr_chunk(avctx, s, length)) < 0)
@@ -1292,12 +1293,12 @@ static int decode_frame_common(AVCodecContext *avctx, 
PNGDecContext *s,
 goto skip_tag;
 break;
 case MKTAG('t', 'E', 'X', 't'):
-if (decode_text_chunk(s, length, 0, metadatap) < 0)
+if (decode_text_chunk(s, length, 0) < 0)
 av_log(avctx, AV_LOG_WARNING, "Broken tEXt chunk\n");
 bytestream2_skip(&s->gb, length + 4);
 break;
 case MKTAG('z', 'T', 'X', 't'):
-if (decode_text_chunk(s, length, 1, metadatap) < 0)
+if (decode_text_chunk(s, length, 1) < 0)
 av_log(avctx, AV_LOG_WARNING, "Broken zTXt chunk\n");
 bytestream2_skip(&s->gb, length + 4);
 break;
@@ -1355,7 +1356,7 @@ static int decode_frame_common(AVCodecContext *avctx, 
PNGDecContext *s,
 if (ret < 0)
 return ret;
 
-av_dict_set(&p->metadata, "gamma", gamma_str, 
AV_DICT_DONT_STRDUP_VAL);
+av_dict_set(&s->frame_metadata, "gamma", gamma_str, 
AV_DICT_DONT_STRDUP_VAL);
 
 bytestream2_skip(&s->gb, 4); /* crc */
 break;
@@ -1466,6 +1467,7 @@ static int decode_frame_png(AVCodecContext *avctx,
 PNGDecContext *const s = avctx->priv_data;
 const uint8_t *buf = avpkt->data;
 int buf_size   = avpkt->size;
+AVFrame *dst_frame = data;
 AVFrame *p = s->picture.f;
 int64_t sig;
 int ret;
@@ -1503,9 +1505,11 @@ static int decode_frame_png(AVCodecContext *avctx,
 goto the_end;
 }
 
-if ((ret = av_frame_ref(data, s->picture.f)) < 0)
+if ((ret = av_frame_ref(dst_frame, s->picture.f)) < 0)
 goto the_end;
 
+FFSWAP(AVDictionary*, dst_frame->metadata, s->frame_metadata);
+
 if (!(avctx->active_thread_type & FF_THREAD_FRAME)) {
 ff_thread_release_buffer(avctx, &s->last_picture);
 FFSWAP(ThreadFrame, s->picture, s->last_picture);
@@ -1527,6 +1531,7 @@ static int decode_frame_apng(AVCodecContext *avctx,
 AVPacket *avpkt)
 {
 PNGDecContext *const s = avctx->priv_data;
+AVFrame *dst_frame = data;
 int ret;
 AVFrame *p = s->picture.f;
 
@@ -1564,6 +1569,8 @@ static int decode_frame_apng(AVCodecContext *avctx,
 if ((ret = av_frame_ref(data, s->picture.f)) < 0)
 goto end;
 
+FFSWAP(AVDictionary*, dst_frame->metadata, s->frame_metadata);
+
 if (!(avctx->active_thread_type & FF_THREAD_FRAME)) {
 if (s->dispose_op == APNG_DISPOSE_OP_PREVIOUS) {
 ff_thread_release_buffer(avctx, &s->pi

[FFmpeg-devel] [PATCH 2/2] FATE: add a test for PNG frame metadata

[Anton Khirnov]

---
 tests/fate/apng.mak|   4 +
 tests/ref/fate/apng-frame-metadata | 270 +
 2 files changed, 274 insertions(+)
 create mode 100644 tests/ref/fate/apng-frame-metadata

diff --git a/tests/fate/apng.mak b/tests/fate/apng.mak
index 0a5f542f19..0d8f191359 100644
--- a/tests/fate/apng.mak
+++ b/tests/fate/apng.mak
@@ -7,6 +7,10 @@ fate-apng-osample: CMD = framecrc -i 
$(TARGET_SAMPLES)/apng/o_sample.png
 FATE_APNG += fate-apng-dispose-previous
 fate-apng-dispose-previous: CMD = framecrc -i 
$(TARGET_SAMPLES)/apng/apng_out_of_order_frames.png
 
+FATE_APNG += fate-apng-frame-metadata
+fate-apng-frame-metadata: CMD = run ffprobe$(PROGSSUF)$(EXESUF) -show_entries 
frame_tags \
+-i $(TARGET_SAMPLES)/apng/apng_out_of_order_frames.png
+
 FATE_APNG-$(call DEMDEC, APNG, APNG) += $(FATE_APNG)
 
 FATE_SAMPLES_FFMPEG += $(FATE_APNG-yes)
diff --git a/tests/ref/fate/apng-frame-metadata 
b/tests/ref/fate/apng-frame-metadata
new file mode 100644
index 00..559562c425
--- /dev/null
+++ b/tests/ref/fate/apng-frame-metadata
@@ -0,0 +1,270 @@
+[FRAME]
+[/FRAME]
+[FRAME]
+[/FRAME]
+[FRAME]
+[/FRAME]
+[FRAME]
+[/FRAME]
+[FRAME]
+[/FRAME]
+[FRAME]
+[/FRAME]
+[FRAME]
+[/FRAME]
+[FRAME]
+[/FRAME]
+[FRAME]
+[/FRAME]
+[FRAME]
+[/FRAME]
+[FRAME]
+[/FRAME]
+[FRAME]
+[/FRAME]
+[FRAME]
+[/FRAME]
+[FRAME]
+[/FRAME]
+[FRAME]
+[/FRAME]
+[FRAME]
+[/FRAME]
+[FRAME]
+[/FRAME]
+[FRAME]
+[/FRAME]
+[FRAME]
+[/FRAME]
+[FRAME]
+[/FRAME]
+[FRAME]
+[/FRAME]
+[FRAME]
+[/FRAME]
+[FRAME]
+[/FRAME]
+[FRAME]
+[/FRAME]
+[FRAME]
+[/FRAME]
+[FRAME]
+[/FRAME]
+[FRAME]
+[/FRAME]
+[FRAME]
+[/FRAME]
+[FRAME]
+[/FRAME]
+[FRAME]
+[/FRAME]
+[FRAME]
+[/FRAME]
+[FRAME]
+[/FRAME]
+[FRAME]
+[/FRAME]
+[FRAME]
+[/FRAME]
+[FRAME]
+[/FRAME]
+[FRAME]
+[/FRAME]
+[FRAME]
+[/FRAME]
+[FRAME]
+[/FRAME]
+[FRAME]
+[/FRAME]
+[FRAME]
+[/FRAME]
+[FRAME]
+[/FRAME]
+[FRAME]
+[/FRAME]
+[FRAME]
+[/FRAME]
+[FRAME]
+[/FRAME]
+[FRAME]
+[/FRAME]
+[FRAME]
+[/FRAME]
+[FRAME]
+[/FRAME]
+[FRAME]
+[/FRAME]
+[FRAME]
+[/FRAME]
+[FRAME]
+[/FRAME]
+[FRAME]
+[/FRAME]
+[FRAME]
+[/FRAME]
+[FRAME]
+[/FRAME]
+[FRAME]
+[/FRAME]
+[FRAME]
+[/FRAME]
+[FRAME]
+[/FRAME]
+[FRAME]
+[/FRAME]
+[FRAME]
+[/FRAME]
+[FRAME]
+[/FRAME]
+[FRAME]
+[/FRAME]
+[FRAME]
+[/FRAME]
+[FRAME]
+[/FRAME]
+[FRAME]
+[/FRAME]
+[FRAME]
+[/FRAME]
+[FRAME]
+[/FRAME]
+[FRAME]
+[/FRAME]
+[FRAME]
+[/FRAME]
+[FRAME]
+[/FRAME]
+[FRAME]
+[/FRAME]
+[FRAME]
+[/FRAME]
+[FRAME]
+[/FRAME]
+[FRAME]
+[/FRAME]
+[FRAME]
+[/FRAME]
+[FRAME]
+[/FRAME]
+[FRAME]
+[/FRAME]
+[FRAME]
+[/FRAME]
+[FRAME]
+[/FRAME]
+[FRAME]
+[/FRAME]
+[FRAME]
+[/FRAME]
+[FRAME]
+[/FRAME]
+[FRAME]
+[/FRAME]
+[FRAME]
+[/FRAME]
+[FRAME]
+[/FRAME]
+[FRAME]
+[/FRAME]
+[FRAME]
+[/FRAME]
+[FRAME]
+[/FRAME]
+[FRAME]
+[/FRAME]
+[FRAME]
+[/FRAME]
+[FRAME]
+[/FRAME]
+[FRAME]
+[/FRAME]
+[FRAME]
+[/FRAME]
+[FRAME]
+[/FRAME]
+[FRAME]
+[/FRAME]
+[FRAME]
+[/FRAME]
+[FRAME]
+[/FRAME]
+[FRAME]
+[/FRAME]
+[FRAME]
+[/FRAME]
+[FRAME]
+[/FRAME]
+[FRAME]
+[/FRAME]
+[FRAME]
+[/FRAME]
+[FRAME]
+[/FRAME]
+[FRAME]
+[/FRAME]
+[FRAME]
+[/FRAME]
+[FRAME]
+[/FRAME]
+[FRAME]
+[/FRAME]
+[FRAME]
+[/FRAME]
+[FRAME]
+[/FRAME]
+[FRAME]
+[/FRAME]
+[FRAME]
+[/FRAME]
+[FRAME]
+[/FRAME]
+[FRAME]
+[/FRAME]
+[FRAME]
+[/FRAME]
+[FRAME]
+[/FRAME]
+[FRAME]
+[/FRAME]
+[FRAME]
+[/FRAME]
+[FRAME]
+[/FRAME]
+[FRAME]
+[/FRAME]
+[FRAME]
+[/FRAME]
+[FRAME]
+[/FRAME]
+[FRAME]
+[/FRAME]
+[FRAME]
+[/FRAME]
+[FRAME]
+[/FRAME]
+[FRAME]
+[/FRAME]
+[FRAME]
+[/FRAME]
+[FRAME]
+[/FRAME]
+[FRAME]
+[/FRAME]
+[FRAME]
+[/FRAME]
+[FRAME]
+[/FRAME]
+[FRAME]
+[/FRAME]
+[FRAME]
+[/FRAME]
+[FRAME]
+[/FRAME]
+[FRAME]
+[/FRAME]
+[FRAME]
+[/FRAME]
+[FRAME]
+TAG:Software=ezgif.com
+TAG:Comment=Resized on https://ezgif.com/resize
+[/FRAME]
-- 
2.30.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] Guided Filter Project | GSoC 2021

[Steven Liu]

> 2021年3月21日 下午6:10，Steven Liu  写道：
> 
> 
> 
>> 2021年3月21日 下午6:03，Paul B Mahol  写道：
>> 
>> 
>> 
>> On Sun, Mar 21, 2021 at 10:58 AM Steven Liu  wrote:
>> 
>> 
>>> 2021年3月21日 下午5:42，Paul B Mahol  写道：
>>> 
>>> 
>>> 
>>> On Sun, Mar 21, 2021 at 10:35 AM Steven Liu  wrote:
>>> 
>>> 
 2021年3月21日 下午5:27，Piyush Chauhan  写道：
 
 Hello Steven,
 
 Eagerly waiting for your reply.
>>> You looks rush to finish this project and finish it, but I think we should 
>>> in the timeline of GSoC.
>>> And there have rule of GSoC, but I cannot sure you have read all of the 
>>> content which I leaved. 
>>> I think if will not so rush to finish this project if you really read that.
>>> 
>>> I so nowhere rushed code :) ..
>> Yes I think you can, but I guess you are not a student right now :D
>> 
>> Yes, I just though that qualified student should post their qualification 
>> work for review on mailing list first so everything is transparent.
> There have maybe student want do there qualification work of this project, i 
> think all of them want sent the code now, but they are focusing on GSoC 
> Timeline now.
fix typo:  s/maybe student/many students/g
> Of course, I can tell them to send there patches on mailing list if you want 
> review at first step.
> I think ffmpeg not only need one guided filter code, but also need found a 
> contributor to make contributing to ffmpeg long time.
> 

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

Re: [FFmpeg-devel] [PATCH 2/2] FATE: add a test for PNG frame metadata

[Andreas Rheinhardt]

Anton Khirnov:
> ---
>  tests/fate/apng.mak|   4 +
>  tests/ref/fate/apng-frame-metadata | 270 +
>  2 files changed, 274 insertions(+)
>  create mode 100644 tests/ref/fate/apng-frame-metadata
> 
> diff --git a/tests/fate/apng.mak b/tests/fate/apng.mak
> index 0a5f542f19..0d8f191359 100644
> --- a/tests/fate/apng.mak
> +++ b/tests/fate/apng.mak
> @@ -7,6 +7,10 @@ fate-apng-osample: CMD = framecrc -i 
> $(TARGET_SAMPLES)/apng/o_sample.png
>  FATE_APNG += fate-apng-dispose-previous
>  fate-apng-dispose-previous: CMD = framecrc -i 
> $(TARGET_SAMPLES)/apng/apng_out_of_order_frames.png
>  
> +FATE_APNG += fate-apng-frame-metadata
> +fate-apng-frame-metadata: CMD = run ffprobe$(PROGSSUF)$(EXESUF) 
> -show_entries frame_tags \
> +-i $(TARGET_SAMPLES)/apng/apng_out_of_order_frames.png
> +
>  FATE_APNG-$(call DEMDEC, APNG, APNG) += $(FATE_APNG)
>  
>  FATE_SAMPLES_FFMPEG += $(FATE_APNG-yes)
> diff --git a/tests/ref/fate/apng-frame-metadata 
> b/tests/ref/fate/apng-frame-metadata
> new file mode 100644
> index 00..559562c425
> --- /dev/null
> +++ b/tests/ref/fate/apng-frame-metadata
> @@ -0,0 +1,270 @@
> +[FRAME]
> +[/FRAME]
> +[FRAME]
> +[/FRAME]
> +[FRAME]
> +[/FRAME]
> +[FRAME]
> +[/FRAME]
> +[FRAME]
> +[/FRAME]
> +[FRAME]
> +[/FRAME]
> +[FRAME]
> +[/FRAME]
> +[FRAME]
> +[/FRAME]
> +[FRAME]
> +[/FRAME]
> +[FRAME]
> +[/FRAME]
> +[FRAME]
> +[/FRAME]
> +[FRAME]
> +[/FRAME]
> +[FRAME]
> +[/FRAME]
> +[FRAME]
> +[/FRAME]
> +[FRAME]
> +[/FRAME]
> +[FRAME]
> +[/FRAME]
> +[FRAME]
> +[/FRAME]
> +[FRAME]
> +[/FRAME]
> +[FRAME]
> +[/FRAME]
> +[FRAME]
> +[/FRAME]
> +[FRAME]
> +[/FRAME]
> +[FRAME]
> +[/FRAME]
> +[FRAME]
> +[/FRAME]
> +[FRAME]
> +[/FRAME]
> +[FRAME]
> +[/FRAME]
> +[FRAME]
> +[/FRAME]
> +[FRAME]
> +[/FRAME]
> +[FRAME]
> +[/FRAME]
> +[FRAME]
> +[/FRAME]
> +[FRAME]
> +[/FRAME]
> +[FRAME]
> +[/FRAME]
> +[FRAME]
> +[/FRAME]
> +[FRAME]
> +[/FRAME]
> +[FRAME]
> +[/FRAME]
> +[FRAME]
> +[/FRAME]
> +[FRAME]
> +[/FRAME]
> +[FRAME]
> +[/FRAME]
> +[FRAME]
> +[/FRAME]
> +[FRAME]
> +[/FRAME]
> +[FRAME]
> +[/FRAME]
> +[FRAME]
> +[/FRAME]
> +[FRAME]
> +[/FRAME]
> +[FRAME]
> +[/FRAME]
> +[FRAME]
> +[/FRAME]
> +[FRAME]
> +[/FRAME]
> +[FRAME]
> +[/FRAME]
> +[FRAME]
> +[/FRAME]
> +[FRAME]
> +[/FRAME]
> +[FRAME]
> +[/FRAME]
> +[FRAME]
> +[/FRAME]
> +[FRAME]
> +[/FRAME]
> +[FRAME]
> +[/FRAME]
> +[FRAME]
> +[/FRAME]
> +[FRAME]
> +[/FRAME]
> +[FRAME]
> +[/FRAME]
> +[FRAME]
> +[/FRAME]
> +[FRAME]
> +[/FRAME]
> +[FRAME]
> +[/FRAME]
> +[FRAME]
> +[/FRAME]
> +[FRAME]
> +[/FRAME]
> +[FRAME]
> +[/FRAME]
> +[FRAME]
> +[/FRAME]
> +[FRAME]
> +[/FRAME]
> +[FRAME]
> +[/FRAME]
> +[FRAME]
> +[/FRAME]
> +[FRAME]
> +[/FRAME]
> +[FRAME]
> +[/FRAME]
> +[FRAME]
> +[/FRAME]
> +[FRAME]
> +[/FRAME]
> +[FRAME]
> +[/FRAME]
> +[FRAME]
> +[/FRAME]
> +[FRAME]
> +[/FRAME]
> +[FRAME]
> +[/FRAME]
> +[FRAME]
> +[/FRAME]
> +[FRAME]
> +[/FRAME]
> +[FRAME]
> +[/FRAME]
> +[FRAME]
> +[/FRAME]
> +[FRAME]
> +[/FRAME]
> +[FRAME]
> +[/FRAME]
> +[FRAME]
> +[/FRAME]
> +[FRAME]
> +[/FRAME]
> +[FRAME]
> +[/FRAME]
> +[FRAME]
> +[/FRAME]
> +[FRAME]
> +[/FRAME]
> +[FRAME]
> +[/FRAME]
> +[FRAME]
> +[/FRAME]
> +[FRAME]
> +[/FRAME]
> +[FRAME]
> +[/FRAME]
> +[FRAME]
> +[/FRAME]
> +[FRAME]
> +[/FRAME]
> +[FRAME]
> +[/FRAME]
> +[FRAME]
> +[/FRAME]
> +[FRAME]
> +[/FRAME]
> +[FRAME]
> +[/FRAME]
> +[FRAME]
> +[/FRAME]
> +[FRAME]
> +[/FRAME]
> +[FRAME]
> +[/FRAME]
> +[FRAME]
> +[/FRAME]
> +[FRAME]
> +[/FRAME]
> +[FRAME]
> +[/FRAME]
> +[FRAME]
> +[/FRAME]
> +[FRAME]
> +[/FRAME]
> +[FRAME]
> +[/FRAME]
> +[FRAME]
> +[/FRAME]
> +[FRAME]
> +[/FRAME]
> +[FRAME]
> +[/FRAME]
> +[FRAME]
> +[/FRAME]
> +[FRAME]
> +[/FRAME]
> +[FRAME]
> +[/FRAME]
> +[FRAME]
> +[/FRAME]
> +[FRAME]
> +[/FRAME]
> +[FRAME]
> +[/FRAME]
> +[FRAME]
> +[/FRAME]
> +[FRAME]
> +[/FRAME]
> +[FRAME]
> +[/FRAME]
> +[FRAME]
> +[/FRAME]
> +[FRAME]
> +[/FRAME]
> +[FRAME]
> +[/FRAME]
> +[FRAME]
> +[/FRAME]
> +[FRAME]
> +[/FRAME]
> +[FRAME]
> +[/FRAME]
> +[FRAME]
> +[/FRAME]
> +[FRAME]
> +[/FRAME]
> +[FRAME]
> +[/FRAME]
> +[FRAME]
> +[/FRAME]
> +[FRAME]
> +[/FRAME]
> +[FRAME]
> +[/FRAME]
> +[FRAME]
> +[/FRAME]
> +[FRAME]
> +[/FRAME]
> +[FRAME]
> +[/FRAME]
> +[FRAME]
> +[/FRAME]
> +[FRAME]
> +[/FRAME]
> +[FRAME]
> +[/FRAME]
> +[FRAME]
> +TAG:Software=ezgif.com
> +TAG:Comment=Resized on https://ezgif.com/resize
> +[/FRAME]
> 
This metadata is also reported now; it is not affected by the
regression. But the files fate-suite/filter/pixelart[01].png are.

- 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] configure: select child muxers for rtp_mpegts

[Gyan Doshi]

Pushed as 36a5ae619a7d255c27f66a343a7861108d789159

On 2021-03-20 19:28, Gyan Doshi wrote:

Will apply tomorrow.

On 2021-03-18 17:56, Gyan Doshi wrote:

---
  configure | 1 +
  1 file changed, 1 insertion(+)

diff --git a/configure b/configure
index f0ac719d2d..be9c5b4b1c 100755
--- a/configure
+++ b/configure
@@ -3363,6 +3363,7 @@ opus_muxer_select="ogg_muxer"
  psp_muxer_select="mov_muxer"
  rtp_demuxer_select="sdp_demuxer"
  rtp_muxer_select="golomb jpegtables"
+rtp_mpegts_muxer_select="mpegts_muxer rtp_muxer"
  rtpdec_select="asf_demuxer jpegtables mov_demuxer mpegts_demuxer 
rm_demuxer rtp_protocol srtp"

  rtsp_demuxer_select="http_protocol rtpdec"
  rtsp_muxer_select="rtp_muxer http_protocol rtp_protocol rtpenc_chain"


___
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] avformat/rtp_mpegts: typedef MuxChain struct

[Gyan Doshi]

Pushed as 75fd3e15190cf72ffcfa15f0fb00f1d9a7ac5b6e

On 2021-03-20 19:28, Gyan Doshi wrote:

Will apply tomorrow.

On 2021-03-18 18:04, Gyan Doshi wrote:

---
  libavformat/rtpenc_mpegts.c | 12 ++--
  1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/libavformat/rtpenc_mpegts.c b/libavformat/rtpenc_mpegts.c
index 50cebf68a3..28522f8913 100644
--- a/libavformat/rtpenc_mpegts.c
+++ b/libavformat/rtpenc_mpegts.c
@@ -23,15 +23,15 @@
  #include "avformat.h"
  #include "avio_internal.h"
  -struct MuxChain {
+typedef struct MuxChain {
  AVFormatContext *mpegts_ctx;
  AVFormatContext *rtp_ctx;
  AVPacket *pkt;
-};
+} MuxChain;
    static int rtp_mpegts_write_close(AVFormatContext *s)
  {
-    struct MuxChain *chain = s->priv_data;
+    MuxChain *chain = s->priv_data;
    if (chain->mpegts_ctx) {
  av_write_trailer(chain->mpegts_ctx);
@@ -50,7 +50,7 @@ static int rtp_mpegts_write_close(AVFormatContext *s)
    static int rtp_mpegts_write_header(AVFormatContext *s)
  {
-    struct MuxChain *chain = s->priv_data;
+    MuxChain *chain = s->priv_data;
  AVFormatContext *mpegts_ctx = NULL, *rtp_ctx = NULL;
  ff_const59 AVOutputFormat *mpegts_format = 
av_guess_format("mpegts", NULL, NULL);
  ff_const59 AVOutputFormat *rtp_format    = 
av_guess_format("rtp", NULL, NULL);

@@ -120,7 +120,7 @@ fail:
    static int rtp_mpegts_write_packet(AVFormatContext *s, AVPacket 
*pkt)

  {
-    struct MuxChain *chain = s->priv_data;
+    MuxChain *chain = s->priv_data;
  int ret = 0, size;
  uint8_t *buf;
  AVPacket *local_pkt = chain->pkt;
@@ -158,7 +158,7 @@ static int 
rtp_mpegts_write_packet(AVFormatContext *s, AVPacket *pkt)

  AVOutputFormat ff_rtp_mpegts_muxer = {
  .name  = "rtp_mpegts",
  .long_name = NULL_IF_CONFIG_SMALL("RTP/mpegts output 
format"),

-    .priv_data_size    = sizeof(struct MuxChain),
+    .priv_data_size    = sizeof(MuxChain),
  .audio_codec   = AV_CODEC_ID_AAC,
  .video_codec   = AV_CODEC_ID_MPEG4,
  .write_header  = rtp_mpegts_write_header,


___
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] lavc/pngdec: fix exporting frame metadata after 5663301560

[Andreas Rheinhardt]

Anton Khirnov:
> Also avoid a potential race with frame threading, where a frame's
> metadata could be modified concurrently with that frame being passed to
> another thread.
> 
> Fixes #8972
> 
> Found-by: Andreas Rheinhardt 
> ---
>  libavcodec/pngdec.c | 27 ++-
>  1 file changed, 18 insertions(+), 9 deletions(-)
> 
> diff --git a/libavcodec/pngdec.c b/libavcodec/pngdec.c
> index a5a71ef161..00fabec34c 100644
> --- a/libavcodec/pngdec.c
> +++ b/libavcodec/pngdec.c
> @@ -57,6 +57,8 @@ typedef struct PNGDecContext {
>  ThreadFrame last_picture;
>  ThreadFrame picture;
>  
> +AVDictionary *frame_metadata;
> +
>  enum PNGHeaderState hdr_state;
>  enum PNGImageState pic_state;
>  int width, height;
> @@ -509,8 +511,7 @@ static uint8_t *iso88591_to_utf8(const uint8_t *in, 
> size_t size_in)
>  return out;
>  }
>  
> -static int decode_text_chunk(PNGDecContext *s, uint32_t length, int 
> compressed,
> - AVDictionary **dict)
> +static int decode_text_chunk(PNGDecContext *s, uint32_t length, int 
> compressed)
>  {
>  int ret, method;
>  const uint8_t *data= s->gb.buffer;
> @@ -552,7 +553,7 @@ static int decode_text_chunk(PNGDecContext *s, uint32_t 
> length, int compressed,
>  return AVERROR(ENOMEM);
>  }
>  
> -av_dict_set(dict, kw_utf8, txt_utf8,
> +av_dict_set(&s->frame_metadata, kw_utf8, txt_utf8,
>  AV_DICT_DONT_STRDUP_KEY | AV_DICT_DONT_STRDUP_VAL);
>  return 0;
>  }
> @@ -710,6 +711,8 @@ static int decode_idat_chunk(AVCodecContext *avctx, 
> PNGDecContext *s,
>  s->bpp += byte_depth;
>  }
>  
> +av_dict_free(&s->frame_metadata);
> +
>  ff_thread_release_buffer(avctx, &s->picture);
>  if ((ret = ff_thread_get_buffer(avctx, &s->picture, 
> AV_GET_BUFFER_FLAG_REF)) < 0)
>  return ret;
> @@ -1182,7 +1185,6 @@ static int decode_frame_common(AVCodecContext *avctx, 
> PNGDecContext *s,
> AVFrame *p, const AVPacket *avpkt)
>  {
>  const AVCRC *crc_tab = av_crc_get_table(AV_CRC_32_IEEE_LE);
> -AVDictionary **metadatap = NULL;
>  uint32_t tag, length;
>  int decode_next_dat = 0;
>  int i, ret;
> @@ -1250,7 +1252,6 @@ static int decode_frame_common(AVCodecContext *avctx, 
> PNGDecContext *s,
>  }
>  }
>  
> -metadatap = &p->metadata;
>  switch (tag) {
>  case MKTAG('I', 'H', 'D', 'R'):
>  if ((ret = decode_ihdr_chunk(avctx, s, length)) < 0)
> @@ -1292,12 +1293,12 @@ static int decode_frame_common(AVCodecContext *avctx, 
> PNGDecContext *s,
>  goto skip_tag;
>  break;
>  case MKTAG('t', 'E', 'X', 't'):
> -if (decode_text_chunk(s, length, 0, metadatap) < 0)
> +if (decode_text_chunk(s, length, 0) < 0)
>  av_log(avctx, AV_LOG_WARNING, "Broken tEXt chunk\n");
>  bytestream2_skip(&s->gb, length + 4);
>  break;
>  case MKTAG('z', 'T', 'X', 't'):
> -if (decode_text_chunk(s, length, 1, metadatap) < 0)
> +if (decode_text_chunk(s, length, 1) < 0)
>  av_log(avctx, AV_LOG_WARNING, "Broken zTXt chunk\n");
>  bytestream2_skip(&s->gb, length + 4);
>  break;
> @@ -1355,7 +1356,7 @@ static int decode_frame_common(AVCodecContext *avctx, 
> PNGDecContext *s,
>  if (ret < 0)
>  return ret;
>  
> -av_dict_set(&p->metadata, "gamma", gamma_str, 
> AV_DICT_DONT_STRDUP_VAL);
> +av_dict_set(&s->frame_metadata, "gamma", gamma_str, 
> AV_DICT_DONT_STRDUP_VAL);
>  
>  bytestream2_skip(&s->gb, 4); /* crc */
>  break;
> @@ -1466,6 +1467,7 @@ static int decode_frame_png(AVCodecContext *avctx,
>  PNGDecContext *const s = avctx->priv_data;
>  const uint8_t *buf = avpkt->data;
>  int buf_size   = avpkt->size;
> +AVFrame *dst_frame = data;
>  AVFrame *p = s->picture.f;
>  int64_t sig;
>  int ret;
> @@ -1503,9 +1505,11 @@ static int decode_frame_png(AVCodecContext *avctx,
>  goto the_end;
>  }
>  
> -if ((ret = av_frame_ref(data, s->picture.f)) < 0)
> +if ((ret = av_frame_ref(dst_frame, s->picture.f)) < 0)
>  goto the_end;
>  
> +FFSWAP(AVDictionary*, dst_frame->metadata, s->frame_metadata);
> +
>  if (!(avctx->active_thread_type & FF_THREAD_FRAME)) {
>  ff_thread_release_buffer(avctx, &s->last_picture);
>  FFSWAP(ThreadFrame, s->picture, s->last_picture);
> @@ -1527,6 +1531,7 @@ static int decode_frame_apng(AVCodecContext *avctx,
>  AVPacket *avpkt)
>  {
>  PNGDecContext *const s = avctx->priv_data;
> +AVFrame *dst_frame = data;
>  int ret;
>  AVFrame *p = s->picture.f;
>  
> @@ -1564,6 +1569,8 @@ static int decode_frame_apng(AVCodecContext *avctx,
>  if ((ret = av_frame_re

Re: [FFmpeg-devel] [PATCH v2] lavfi/qsvvpp: support async depth

[Linjie Fu]

Hi Fei,

On Mon, Mar 15, 2021 at 1:13 PM Fei Wang  wrote:
>
> Async depth will allow qsv filter cache few frames, and avoid force
> switch and end filter task frame by frame. This change will improve
> performance for some multi-task case, for example 1:N transcode(
> decode + vpp + encode) with all QSV plugins.

Async depth support for qsv vpp is valuable for the performance of
whole qsv pipeline, since both decoding/encoding have already
supported the async_depth.

Hence, would you please help to elaborate more about the details about
the performance improvement for the whole pipeline?
(For examples,  before/after this patch, cmdline, platform and the fps ...)

> Signed-off-by: Fei Wang 
> ---
> Change: combine used and queued into queued in QSVFrame.
>
>  libavfilter/qsvvpp.c | 153 ++-
>  libavfilter/qsvvpp.h |  41 -
>  libavfilter/vf_deinterlace_qsv.c |  14 +--
>  libavfilter/vf_vpp_qsv.c |  75 ---
>  4 files changed, 193 insertions(+), 90 deletions(-)
>
> diff --git a/libavfilter/qsvvpp.c b/libavfilter/qsvvpp.c
> index f216b3f248..e7c7a12cfa 100644
> --- a/libavfilter/qsvvpp.c
> +++ b/libavfilter/qsvvpp.c
> @@ -27,6 +27,7 @@
>  #include "libavutil/hwcontext_qsv.h"
>  #include "libavutil/time.h"
>  #include "libavutil/pixdesc.h"
> +#include "libavutil/fifo.h"

This seems to be redundant, since you're adding fifo.h in qsvvpp.h as well.

>  #include "internal.h"
>  #include "qsvvpp.h"
> @@ -37,37 +38,6 @@
>  #define IS_OPAQUE_MEMORY(mode) (mode & MFX_MEMTYPE_OPAQUE_FRAME)
>  #define IS_SYSTEM_MEMORY(mode) (mode & MFX_MEMTYPE_SYSTEM_MEMORY)
>
> -typedef struct QSVFrame {
> -AVFrame  *frame;
> -mfxFrameSurface1 *surface;
> -mfxFrameSurface1  surface_internal;  /* for system memory */
> -struct QSVFrame  *next;
> -} QSVFrame;
> -
> -/* abstract struct for all QSV filters */
> -struct QSVVPPContext {
> -mfxSession  session;
> -int (*filter_frame) (AVFilterLink *outlink, AVFrame *frame);/* callback 
> */
> -enum AVPixelFormat  out_sw_format;   /* Real output format */
> -mfxVideoParam   vpp_param;
> -mfxFrameInfo   *frame_infos; /* frame info for each input */
> -
> -/* members related to the input/output surface */
> -int in_mem_mode;
> -int out_mem_mode;
> -QSVFrame   *in_frame_list;
> -QSVFrame   *out_frame_list;
> -int nb_surface_ptrs_in;
> -int nb_surface_ptrs_out;
> -mfxFrameSurface1  **surface_ptrs_in;
> -mfxFrameSurface1  **surface_ptrs_out;
> -
> -/* MFXVPP extern parameters */
> -mfxExtOpaqueSurfaceAlloc opaque_alloc;
> -mfxExtBuffer  **ext_buffers;
> -int nb_ext_buffers;
> -};
> -
>  static const mfxHandleType handle_types[] = {
>  MFX_HANDLE_VA_DISPLAY,
>  MFX_HANDLE_D3D9_DEVICE_MANAGER,
> @@ -336,9 +306,11 @@ static int fill_frameinfo_by_link(mfxFrameInfo 
> *frameinfo, AVFilterLink *link)
>  static void clear_unused_frames(QSVFrame *list)
>  {
>  while (list) {
> -if (list->surface && !list->surface->Data.Locked) {
> -list->surface = NULL;
> +/* list->queued==1 means the frame is not cached in VPP
> + * process any more, it can be released to pool. */
> +if ((list->queued == 1) && !list->surface.Data.Locked) {
>  av_frame_free(&list->frame);
> +list->queued = 0;
>  }
>  list = list->next;
>  }
> @@ -361,8 +333,10 @@ static QSVFrame *get_free_frame(QSVFrame **list)
>  QSVFrame *out = *list;
>
>  for (; out; out = out->next) {
> -if (!out->surface)
> +if (!out->queued) {
> +out->queued = 1;
>  break;
> +}
>  }
>
>  if (!out) {
> @@ -371,8 +345,9 @@ static QSVFrame *get_free_frame(QSVFrame **list)
>  av_log(NULL, AV_LOG_ERROR, "Can't alloc new output frame.\n");
>  return NULL;
>  }
> -out->next  = *list;
> -*list  = out;
> +out->queued = 1;
> +out->next   = *list;
> +*list   = out;
>  }
>
>  return out;
> @@ -402,7 +377,7 @@ static QSVFrame *submit_frame(QSVVPPContext *s, 
> AVFilterLink *inlink, AVFrame *p
>  return NULL;
>  }
>  qsv_frame->frame   = av_frame_clone(picref);
> -qsv_frame->surface = (mfxFrameSurface1 *)qsv_frame->frame->data[3];
> +qsv_frame->surface = *(mfxFrameSurface1 *)qsv_frame->frame->data[3];

The type of surface in struct QSVFrame  would be changed fron
*mfxFrameSurface1 to mfxFrameSurface1, and surface_internal would be
removed.
IMO separating the related changes for the structures into a single
commit would make it more explicit, since it's not closely related
with the implemetation of async fifo.

- linjie
___
ffmpeg-devel mailing list
ffmpeg-deve

Re: [FFmpeg-devel] [PATCH 1/2] lavc/pngdec: fix exporting frame metadata after 5663301560

[Carl Eugen Hoyos]

Am So., 21. März 2021 um 11:15 Uhr schrieb Anton Khirnov :
>
> Also avoid a potential race with frame threading, where a frame's
> metadata could be modified concurrently with that frame being passed to
> another thread.
>
> Fixes #8972

Ticket #8972 is definitely reproducible with versions older than 5663301560

Carl Eugen
___
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] Guided Filter Project | GSoC 2021

[Piyush Chauhan]

>
> You looks rush to finish this project and finish it, but I think we should
> in the timeline of GSoC.
> And there have rule of GSoC, but I cannot sure you have read all of the
> content which I leaved.
> I think if will not so rush to finish this project if you really read that.
>
My apologies, I see you have updated the qualification task.

> Passing qualification will be judged by having high perfomance than
> Kaiming He's origin algrithmns working code for guided filter pushed into
> FFmpeg git.

I'll try working towards the performance part of the algorithm.
But, I thought I have to post my code for the qualification task.
I need some clarification on this.

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

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

Re: [FFmpeg-devel] Guided Filter Project | GSoC 2021

[Steven Liu]

> 2021年3月21日 下午6:09，Piyush Chauhan  写道：
> 
>> 
>> You looks rush to finish this project and finish it, but I think we should
>> in the timeline of GSoC.
>> And there have rule of GSoC, but I cannot sure you have read all of the
>> content which I leaved.
>> I think if will not so rush to finish this project if you really read that.
>> 
> My apologies, I see you have updated the qualification task.
> 
>> Passing qualification will be judged by having high perfomance than
>> Kaiming He's origin algrithmns working code for guided filter pushed into
>> FFmpeg git.
> 
> I'll try working towards the performance part of the algorithm.
> But, I thought I have to post my code for the qualification task.
> I need some clarification on this.


Yes, that is ok if you want, and other students can post their code too.
I think I need clarify that you have half chance for the qualification.
And I have not seen your name on the dashboard, of course I have not seen this 
project on the dashboard too now. 
Dashboard link : https://summerofcode.withgoogle.com/dashboard/

> 
> Thanks
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

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

Re: [FFmpeg-devel] Guided Filter Project | GSoC 2021

[Piyush Chauhan]

>
> 21 Mar 2021, 17:01, Steven Liu 
>
Yes, that is ok if you want, and other students can post their code too.
> I think I need clarify that you have half chance for the qualification.
> And I have not seen your name on the dashboard, of course I have not seen
> this project on the dashboard too now.
> Dashboard link : https://summerofcode.withgoogle.com/dashboard/


Hey Steven, I don't think the dashboard become active until after the
announcement of the students i.e after May.
And the above link is showing 403 to me.
Please correct me if I am wrong.

Thanks

On Sun, 21 Mar 2021 at 17:01, Steven Liu  wrote:

>
>
> > 2021年3月21日 下午6:09，Piyush Chauhan  写道：
> >
> >>
> >> You looks rush to finish this project and finish it, but I think we
> should
> >> in the timeline of GSoC.
> >> And there have rule of GSoC, but I cannot sure you have read all of the
> >> content which I leaved.
> >> I think if will not so rush to finish this project if you really read
> that.
> >>
> > My apologies, I see you have updated the qualification task.
> >
> >> Passing qualification will be judged by having high perfomance than
> >> Kaiming He's origin algrithmns working code for guided filter pushed
> into
> >> FFmpeg git.
> >
> > I'll try working towards the performance part of the algorithm.
> > But, I thought I have to post my code for the qualification task.
> > I need some clarification on this.
>
>
> Yes, that is ok if you want, and other students can post their code too.
> I think I need clarify that you have half chance for the qualification.
> And I have not seen your name on the dashboard, of course I have not seen
> this project on the dashboard too now.
> Dashboard link : https://summerofcode.withgoogle.com/dashboard/
>
> >
> > Thanks
> > ___
> > ffmpeg-devel mailing list
> > ffmpeg-devel@ffmpeg.org
> > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> >
> > To unsubscribe, visit link above, or email
> > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
>
> 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".
___
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] Guided Filter Project | GSoC 2021

[Steven Liu]

> 2021年3月21日 下午8:00，Piyush Chauhan  写道：
> 
>> 
>> 21 Mar 2021, 17:01, Steven Liu 
>> 
> Yes, that is ok if you want, and other students can post their code too.
>> I think I need clarify that you have half chance for the qualification.
>> And I have not seen your name on the dashboard, of course I have not seen
>> this project on the dashboard too now.
>> Dashboard link : https://summerofcode.withgoogle.com/dashboard/
> 
> 
> Hey Steven, I don't think the dashboard become active until after the
> announcement of the students i.e after May.
> And the above link is showing 403 to me.
> Please correct me if I am wrong.


I saw the timeline said:
Organizations Announced
March 10, 2021
Interested students can now begin discussing project ideas with accepted mentor 
organizations.


I should update the “Qualification Task" and "Expected results” after talk with 
you and other students, you can touch me change these objects any time.


Student Application Period
March 30, 2021 - April 14, 2021
Students can register and submit their applications to mentor organizations. 
All proposals must be submitted by April 14, 2021 02:00 (CST).

I think this is the result of which student should do the whole project.

You can correct me if I am wrong. :D


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

Re: [FFmpeg-devel] Guided Filter Project | GSoC 2021

[Steven Liu]

> 2021年3月21日 下午8:07，Steven Liu  写道：
> 
>> 
>> 2021年3月21日 下午8:00，Piyush Chauhan  写道：
>> 
>>> 
>>> 21 Mar 2021, 17:01, Steven Liu 
>>> 
>> Yes, that is ok if you want, and other students can post their code too.
>>> I think I need clarify that you have half chance for the qualification.
>>> And I have not seen your name on the dashboard, of course I have not seen
>>> this project on the dashboard too now.
>>> Dashboard link : https://summerofcode.withgoogle.com/dashboard/
>> 
>> 
>> Hey Steven, I don't think the dashboard become active until after the
>> announcement of the students i.e after May.
>> And the above link is showing 403 to me.
>> Please correct me if I am wrong.
> 
> 
Hi Piyush Chauhan,

apology I forget paste the reference link : 
https://summerofcode.withgoogle.com/how-it-works/

> I saw the timeline said:
> Organizations Announced
> March 10, 2021
> Interested students can now begin discussing project ideas with accepted 
> mentor organizations.
> 
> 
> I should update the “Qualification Task" and "Expected results” after talk 
> with you and other students, you can touch me change these objects any time.
> 
> 
> Student Application Period
> March 30, 2021 - April 14, 2021
> Students can register and submit their applications to mentor organizations. 
> All proposals must be submitted by April 14, 2021 02:00 (CST).
> 
> I think this is the result of which student should do the whole project.
> 
> You can correct me if I am wrong. :D
> 
> 
> Thanks
> 
> Steven Liu

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

[FFmpeg-devel] Re: [PATCH 01/48] avcodec/packet: deprecate av_init_packet()

[Anton Khirnov]

Quoting James Almer (2021-03-05 17:32:52)
> diff --git a/libavformat/avformat.h b/libavformat/avformat.h
> index 7da2f3d98e..783cc1b591 100644
> --- a/libavformat/avformat.h
> +++ b/libavformat/avformat.h
> @@ -954,7 +954,11 @@ typedef struct AVStream {
>   * decoding: set by libavformat, must not be modified by the caller.
>   * encoding: unused
>   */
> +#if FF_API_INIT_PACKET
>  AVPacket attached_pic;
> +#else
> +AVPacket *attached_pic;
> +#endif

Sorry I'm late to the party, but as we are changing the type of an
existing field, we need to explicitly spell out a way for the callers to
make their code forward compatible. E.g. similarly to what I made for
thread_safe_callbacks deprecation.

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

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

[FFmpeg-devel] [PATCH 1/4] avfilter/vf_v360: fix fov_from_hfov for fisheye

[Daniel Playfair Cal]

This was previously incorrect, so that passing only id_fov or d_fov
resulted in incorrect transformation.

Signed-off-by: Daniel Playfair Cal 
---
 libavfilter/vf_v360.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/libavfilter/vf_v360.c b/libavfilter/vf_v360.c
index 94473cd5b3..425f04da94 100644
--- a/libavfilter/vf_v360.c
+++ b/libavfilter/vf_v360.c
@@ -4045,10 +4045,10 @@ static void fov_from_dfov(int format, float d_fov, 
float w, float h, float *h_fo
 break;
 case FISHEYE:
 {
-const float d = 0.5f * hypotf(w, h);
+const float d = hypotf(w, h);
 
-*h_fov = d / w * d_fov;
-*v_fov = d / h * d_fov;
+*h_fov = w / d * d_fov;
+*v_fov = h / d * d_fov;
 }
 break;
 case FLAT:
-- 
2.31.0

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

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

[FFmpeg-devel] [PATCH 4/4] avfilter/vf_v360: refactor (i)flat_range for fisheye

[Daniel Playfair Cal]

This changes the iflat_range and flat_range values for the fisheye
projection to match their meaning for the flat/rectilinear projection.
That is, the range is between the two x or two y coordinates of the
outermost points above/below or left/right of the center, in the
flat/rectilinear projection.

Signed-off-by: Daniel Playfair Cal 
---
 libavfilter/vf_v360.c | 19 +--
 1 file changed, 9 insertions(+), 10 deletions(-)

diff --git a/libavfilter/vf_v360.c b/libavfilter/vf_v360.c
index 68bb2f7b0f..3158451963 100644
--- a/libavfilter/vf_v360.c
+++ b/libavfilter/vf_v360.c
@@ -2807,9 +2807,8 @@ static int prepare_fisheye_out(AVFilterContext *ctx)
 {
 V360Context *s = ctx->priv;
 
-s->flat_range[0] = s->h_fov / 180.f;
-s->flat_range[1] = s->v_fov / 180.f;
-
+s->flat_range[0] = 0.5f * s->h_fov * M_PI / 180.f;
+s->flat_range[1] = 0.5f * s->v_fov * M_PI / 180.f;
 return 0;
 }
 
@@ -2827,8 +2826,8 @@ static int fisheye_to_xyz(const V360Context *s,
   int i, int j, int width, int height,
   float *vec)
 {
-const float uf = s->flat_range[0] * ((2.f * i) / width  - 1.f);
-const float vf = s->flat_range[1] * ((2.f * j + 1.f) / height - 1.f);
+const float uf = 2.f * s->flat_range[0] / M_PI * ((2.f * i) / width  - 
1.f);
+const float vf = 2.f * s->flat_range[1] / M_PI * ((2.f * j + 1.f) / height 
- 1.f);
 
 const float phi   = atan2f(vf, uf);
 const float theta = M_PI_2 * (1.f - hypotf(uf, vf));
@@ -2858,8 +2857,8 @@ static int prepare_fisheye_in(AVFilterContext *ctx)
 {
 V360Context *s = ctx->priv;
 
-s->iflat_range[0] = s->ih_fov / 180.f;
-s->iflat_range[1] = s->iv_fov / 180.f;
+s->iflat_range[0] = 0.5f * s->ih_fov * M_PI / 180.f;
+s->iflat_range[1] = 0.5f * s->iv_fov * M_PI / 180.f;
 
 return 0;
 }
@@ -2882,10 +2881,10 @@ static int xyz_to_fisheye(const V360Context *s,
 {
 const float h   = hypotf(vec[0], vec[1]);
 const float lh  = h > 0.f ? h : 1.f;
-const float phi = atan2f(h, vec[2]) / M_PI;
+const float phi = atan2f(h, vec[2]);
 
-float uf = vec[0] / lh * phi / s->iflat_range[0];
-float vf = vec[1] / lh * phi / s->iflat_range[1];
+float uf = 0.5f * vec[0] / lh * phi / s->iflat_range[0];
+float vf = 0.5f * vec[1] / lh * phi / s->iflat_range[1];
 
 const int visible = -0.5f < uf && uf < 0.5f && -0.5f < vf && vf < 0.5f;
 int ui, vi;
-- 
2.31.0

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

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

[FFmpeg-devel] [PATCH 3/4] avfilter/vf_v360: fix visibility test for fisheye

[Daniel Playfair Cal]

Previously the visibility test referred to a circle in the input. This
changes it so that it refers accurately to the entire area in the input.

Signed-off-by: Daniel Playfair Cal 
---
 libavfilter/vf_v360.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavfilter/vf_v360.c b/libavfilter/vf_v360.c
index be886e9bb1..68bb2f7b0f 100644
--- a/libavfilter/vf_v360.c
+++ b/libavfilter/vf_v360.c
@@ -2887,7 +2887,7 @@ static int xyz_to_fisheye(const V360Context *s,
 float uf = vec[0] / lh * phi / s->iflat_range[0];
 float vf = vec[1] / lh * phi / s->iflat_range[1];
 
-const int visible = hypotf(uf, vf) <= 0.5f;
+const int visible = -0.5f < uf && uf < 0.5f && -0.5f < vf && vf < 0.5f;
 int ui, vi;
 
 uf = (uf + 0.5f) * width;
-- 
2.31.0

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

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

[FFmpeg-devel] [PATCH 2/4] avfilter/vf_v360: stop doubling width for fisheye

[Daniel Playfair Cal]

This resulted in the default aspect ratio being doubled relative to most
input formats like flat/rectilinear. After this patch the default aspect
ratio is the same as a rectilinear input.

Signed-off-by: Daniel Playfair Cal 
---
 libavfilter/vf_v360.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/libavfilter/vf_v360.c b/libavfilter/vf_v360.c
index 425f04da94..be886e9bb1 100644
--- a/libavfilter/vf_v360.c
+++ b/libavfilter/vf_v360.c
@@ -4365,7 +4365,7 @@ static int config_output(AVFilterLink *outlink)
 case FISHEYE:
 s->in_transform = xyz_to_fisheye;
 err = prepare_fisheye_in(ctx);
-wf = w * 2;
+wf = w;
 hf = h;
 break;
 case PANNINI:
@@ -4513,7 +4513,7 @@ static int config_output(AVFilterLink *outlink)
 case FISHEYE:
 s->out_transform = fisheye_to_xyz;
 prepare_out = prepare_fisheye_out;
-w = lrintf(wf * 0.5f);
+w = lrintf(wf);
 h = lrintf(hf);
 break;
 case PANNINI:
-- 
2.31.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] vf_v360: fix (i)flat_range for fisheye projection

[Daniel Playfair Cal]

Sure, I've done so. I'm pretty new to sending patches by email so sorry if
it's a bit messy!

On Sun, Mar 21, 2021 at 8:14 PM Paul B Mahol  wrote:

> Please make log message consistent with other commits to this file.
>
> Also make set of patches to be applied all at once instead each single one.
>
> On Fri, Mar 19, 2021 at 1:08 PM Daniel Playfair Cal <
> daniel.playfair@gmail.com> wrote:
>
>> This changes the iflat_range and flat_range values for the fisheye
>> projection so that they indicate the maximum angle between an observed
>> point and the center (direction the camera is facing). This matches the
>> meaning of those variables in the flat projection.
>>
>> Signed-off-by: Daniel Playfair Cal 
>> ---
>>
>> Sorry for the previous identical patch, this version really does remove
>> the use of double literals.
>>
>>  libavfilter/vf_v360.c | 19 +--
>>  1 file changed, 9 insertions(+), 10 deletions(-)
>>
>> diff --git a/libavfilter/vf_v360.c b/libavfilter/vf_v360.c
>> index 94473cd5b3..7535612d34 100644
>> --- a/libavfilter/vf_v360.c
>> +++ b/libavfilter/vf_v360.c
>> @@ -2807,9 +2807,8 @@ static int prepare_fisheye_out(AVFilterContext *ctx)
>>  {
>>  V360Context *s = ctx->priv;
>>
>> -s->flat_range[0] = s->h_fov / 180.f;
>> -s->flat_range[1] = s->v_fov / 180.f;
>> -
>> +s->flat_range[0] = 0.5f * s->h_fov * M_PI / 180.f;
>> +s->flat_range[1] = 0.5f * s->v_fov * M_PI / 180.f;
>>  return 0;
>>  }
>>
>> @@ -2827,8 +2826,8 @@ static int fisheye_to_xyz(const V360Context *s,
>>int i, int j, int width, int height,
>>float *vec)
>>  {
>> -const float uf = s->flat_range[0] * ((2.f * i) / width  - 1.f);
>> -const float vf = s->flat_range[1] * ((2.f * j + 1.f) / height - 1.f);
>> +const float uf = 2.f * s->flat_range[0] / M_PI * ((2.f * i) / width
>> - 1.f);
>> +const float vf = 2.f * s->flat_range[1] / M_PI * ((2.f * j + 1.f) /
>> height - 1.f);
>>
>>  const float phi   = atan2f(vf, uf);
>>  const float theta = M_PI_2 * (1.f - hypotf(uf, vf));
>> @@ -2858,8 +2857,8 @@ static int prepare_fisheye_in(AVFilterContext *ctx)
>>  {
>>  V360Context *s = ctx->priv;
>>
>> -s->iflat_range[0] = s->ih_fov / 180.f;
>> -s->iflat_range[1] = s->iv_fov / 180.f;
>> +s->iflat_range[0] = 0.5f * s->ih_fov * M_PI / 180.f;
>> +s->iflat_range[1] = 0.5f * s->iv_fov * M_PI / 180.f;
>>
>>  return 0;
>>  }
>> @@ -2882,10 +2881,10 @@ static int xyz_to_fisheye(const V360Context *s,
>>  {
>>  const float h   = hypotf(vec[0], vec[1]);
>>  const float lh  = h > 0.f ? h : 1.f;
>> -const float phi = atan2f(h, vec[2]) / M_PI;
>> +const float phi = atan2f(h, vec[2]);
>>
>> -float uf = vec[0] / lh * phi / s->iflat_range[0];
>> -float vf = vec[1] / lh * phi / s->iflat_range[1];
>> +float uf = 0.5f * vec[0] / lh * phi / s->iflat_range[0];
>> +float vf = 0.5f * vec[1] / lh * phi / s->iflat_range[1];
>>
>>  const int visible = hypotf(uf, vf) <= 0.5f;
>>  int ui, vi;
>> --
>> 2.31.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] avcodec/hevc_cabac: cabac_init_state, do not use magic number which not listed on the spec

[Nuo Mi]

On Sun, Mar 21, 2021 at 4:33 PM Carl Eugen Hoyos  wrote:

> Am So., 21. März 2021 um 06:13 Uhr schrieb Nuo Mi :
> >
> > Magic number 124 and ^= are not listed on the spec.
> > Strictly following the spec will make a reader's life much easier. See
> (9-6) for details
>
> But FFmpeg is not providing a reference application for the reader,
> this is software actually used by real people (both as a library in
> other projects and in the ffmpeg application).
>
> Afaict, the question is if the hevc cabac reader is faster or slower
> with your patch.
> It looks to me as if you are replacing one condition with two conditions.
>
Hi Carl,
Thanks for the review.
It's not a time-sensitive code. We only call them at tile/slice start.
A readable code will help us fix bug easier.

>
> Carl Eugen

___
> 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 01/48] avcodec/packet: deprecate av_init_packet()

[James Almer]

On 3/21/2021 9:28 AM, Anton Khirnov wrote:

Quoting James Almer (2021-03-05 17:32:52)

diff --git a/libavformat/avformat.h b/libavformat/avformat.h
index 7da2f3d98e..783cc1b591 100644
--- a/libavformat/avformat.h
+++ b/libavformat/avformat.h
@@ -954,7 +954,11 @@ typedef struct AVStream {
   * decoding: set by libavformat, must not be modified by the caller.
   * encoding: unused
   */
+#if FF_API_INIT_PACKET
  AVPacket attached_pic;
+#else
+AVPacket *attached_pic;
+#endif


Sorry I'm late to the party, but as we are changing the type of an
existing field, we need to explicitly spell out a way for the callers to
make their code forward compatible. E.g. similarly to what I made for
thread_safe_callbacks deprecation.


What do you suggest? The field is not printing deprecation warnings, so 
would a doxy comment be enough for people to notice it?
Have we done a similar change before? I know at least for symbols like 
public functions we never change their signature in an incompatible way, 
and instead replace them altogether.


Maybe we could add the deprecated attribute to attached_pic, introduce a 
temporary getter function that returns a pointer to the packet, mention 
in the doxy that the field is not going away, is just changing types, 
and they have the option of using the getter for a fire-and-forget 
migration process, then maybe deprecate and eventually remove the getter 
after the switch is done.

___
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] Re: [PATCH 01/48] avcodec/packet: deprecate av_init_packet()

[Anton Khirnov]

Quoting James Almer (2021-03-21 14:54:22)
> On 3/21/2021 9:28 AM, Anton Khirnov wrote:
> > Quoting James Almer (2021-03-05 17:32:52)
> >> diff --git a/libavformat/avformat.h b/libavformat/avformat.h
> >> index 7da2f3d98e..783cc1b591 100644
> >> --- a/libavformat/avformat.h
> >> +++ b/libavformat/avformat.h
> >> @@ -954,7 +954,11 @@ typedef struct AVStream {
> >>* decoding: set by libavformat, must not be modified by the caller.
> >>* encoding: unused
> >>*/
> >> +#if FF_API_INIT_PACKET
> >>   AVPacket attached_pic;
> >> +#else
> >> +AVPacket *attached_pic;
> >> +#endif
> > 
> > Sorry I'm late to the party, but as we are changing the type of an
> > existing field, we need to explicitly spell out a way for the callers to
> > make their code forward compatible. E.g. similarly to what I made for
> > thread_safe_callbacks deprecation.
> 
> What do you suggest? The field is not printing deprecation warnings, so 
> would a doxy comment be enough for people to notice it?
> Have we done a similar change before? I know at least for symbols like 
> public functions we never change their signature in an incompatible way, 
> and instead replace them altogether.
> 
> Maybe we could add the deprecated attribute to attached_pic, introduce a 
> temporary getter function that returns a pointer to the packet, mention 
> in the doxy that the field is not going away, is just changing types, 
> and they have the option of using the getter for a fire-and-forget 
> migration process, then maybe deprecate and eventually remove the getter 
> after the switch is done.

This seems like a lot of hoops to jump through. Wouldn't it then be
better to just add a new field with a new name?

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

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

Re: [FFmpeg-devel] [PATCH 01/48] avcodec/packet: deprecate av_init_packet()

[James Almer]

On 3/21/2021 11:16 AM, Anton Khirnov wrote:

Quoting James Almer (2021-03-21 14:54:22)

On 3/21/2021 9:28 AM, Anton Khirnov wrote:

Quoting James Almer (2021-03-05 17:32:52)

diff --git a/libavformat/avformat.h b/libavformat/avformat.h
index 7da2f3d98e..783cc1b591 100644
--- a/libavformat/avformat.h
+++ b/libavformat/avformat.h
@@ -954,7 +954,11 @@ typedef struct AVStream {
* decoding: set by libavformat, must not be modified by the caller.
* encoding: unused
*/
+#if FF_API_INIT_PACKET
   AVPacket attached_pic;
+#else
+AVPacket *attached_pic;
+#endif


Sorry I'm late to the party, but as we are changing the type of an
existing field, we need to explicitly spell out a way for the callers to
make their code forward compatible. E.g. similarly to what I made for
thread_safe_callbacks deprecation.


What do you suggest? The field is not printing deprecation warnings, so
would a doxy comment be enough for people to notice it?
Have we done a similar change before? I know at least for symbols like
public functions we never change their signature in an incompatible way,
and instead replace them altogether.

Maybe we could add the deprecated attribute to attached_pic, introduce a
temporary getter function that returns a pointer to the packet, mention
in the doxy that the field is not going away, is just changing types,
and they have the option of using the getter for a fire-and-forget
migration process, then maybe deprecate and eventually remove the getter
after the switch is done.


This seems like a lot of hoops to jump through. Wouldn't it then be
better to just add a new field with a new name?


A name change just because it's now a pointer seems overkill. Library 
users that want to support both lavc 59 and 60 will have to add 
preprocessor checks to their code anyway, so using the same name or 
another will not make any difference in that regard. Only a getter would 
prevent ifdeffery, but i agree it's also annoying, and we're about to 
get rid of a dozen of those in the upcoming bump. It also couldn't be 
added to 4.4 since that was already branched out.


How about adding the deprecation attribute to prompt people to read the 
doxy, where we state the field is not going away, just changing types? 
Otherwise i don't think people will notice.

___
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] Re: [PATCH 01/48] avcodec/packet: deprecate av_init_packet()

[Anton Khirnov]

Quoting James Almer (2021-03-21 15:24:35)
> On 3/21/2021 11:16 AM, Anton Khirnov wrote:
> > Quoting James Almer (2021-03-21 14:54:22)
> >> On 3/21/2021 9:28 AM, Anton Khirnov wrote:
> >>> Quoting James Almer (2021-03-05 17:32:52)
>  diff --git a/libavformat/avformat.h b/libavformat/avformat.h
>  index 7da2f3d98e..783cc1b591 100644
>  --- a/libavformat/avformat.h
>  +++ b/libavformat/avformat.h
>  @@ -954,7 +954,11 @@ typedef struct AVStream {
>  * decoding: set by libavformat, must not be modified by the 
>  caller.
>  * encoding: unused
>  */
>  +#if FF_API_INIT_PACKET
> AVPacket attached_pic;
>  +#else
>  +AVPacket *attached_pic;
>  +#endif
> >>>
> >>> Sorry I'm late to the party, but as we are changing the type of an
> >>> existing field, we need to explicitly spell out a way for the callers to
> >>> make their code forward compatible. E.g. similarly to what I made for
> >>> thread_safe_callbacks deprecation.
> >>
> >> What do you suggest? The field is not printing deprecation warnings, so
> >> would a doxy comment be enough for people to notice it?
> >> Have we done a similar change before? I know at least for symbols like
> >> public functions we never change their signature in an incompatible way,
> >> and instead replace them altogether.
> >>
> >> Maybe we could add the deprecated attribute to attached_pic, introduce a
> >> temporary getter function that returns a pointer to the packet, mention
> >> in the doxy that the field is not going away, is just changing types,
> >> and they have the option of using the getter for a fire-and-forget
> >> migration process, then maybe deprecate and eventually remove the getter
> >> after the switch is done.
> > 
> > This seems like a lot of hoops to jump through. Wouldn't it then be
> > better to just add a new field with a new name?
> 
> A name change just because it's now a pointer seems overkill. Library 
> users that want to support both lavc 59 and 60 will have to add 
> preprocessor checks to their code anyway, so using the same name or 
> another will not make any difference in that regard. Only a getter would 
> prevent ifdeffery, but i agree it's also annoying, and we're about to 
> get rid of a dozen of those in the upcoming bump. It also couldn't be 
> added to 4.4 since that was already branched out.
> 
> How about adding the deprecation attribute to prompt people to read the 
> doxy, where we state the field is not going away, just changing types? 
> Otherwise i don't think people will notice.

That is also an acceptable solution.

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

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

Re: [FFmpeg-devel] [PATCH 1/2] avformat/mov: Fix extended atom size buffer length check

[Derek Buitenhuis]

On 18/03/2021 16:14, Derek Buitenhuis wrote:
> When extended atom size support was added to probing in
> fec4a2d232d7ebf6d1084fb568d4d84844f25abc, the buffer
> size check was backwards, but probing continued to work
> because there was no minimum size check yet, so despite
> size being 1 on these atoms, and failing to read the 64-bit
> size, the tag was still correctly read.
> 
> When 0b78016b2d7c36b32d07669c0c86bc4b4225ec98 introduced a
> minimum size check, this exposed the bug, and broke probing
> any files with extended atom sizes, such as entirely valid
> large files that start whith mdat atoms.
> 
> Signed-off-by: Derek Buitenhuis 
> ---
>  libavformat/mov.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

I synced the FATE sample and will push these a little later today unless there 
are comments.

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

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

Re: [FFmpeg-devel] [PATCH 4/4] avfilter/vf_v360: refactor (i)flat_range for fisheye

[Paul B Mahol]

Sorry, but I cannot apply this set as is, It makes at least one serious
regression.

For example try this filtergraph:

v360=input=e:output=fisheye:h_fov=180:v_fov=180,v360=input=fisheye:output=e:ih_fov=180:iv_fov=180

On Sun, Mar 21, 2021 at 1:45 PM Daniel Playfair Cal <
daniel.playfair@gmail.com> wrote:

> This changes the iflat_range and flat_range values for the fisheye
> projection to match their meaning for the flat/rectilinear projection.
> That is, the range is between the two x or two y coordinates of the
> outermost points above/below or left/right of the center, in the
> flat/rectilinear projection.
>
> Signed-off-by: Daniel Playfair Cal 
> ---
>  libavfilter/vf_v360.c | 19 +--
>  1 file changed, 9 insertions(+), 10 deletions(-)
>
> diff --git a/libavfilter/vf_v360.c b/libavfilter/vf_v360.c
> index 68bb2f7b0f..3158451963 100644
> --- a/libavfilter/vf_v360.c
> +++ b/libavfilter/vf_v360.c
> @@ -2807,9 +2807,8 @@ static int prepare_fisheye_out(AVFilterContext *ctx)
>  {
>  V360Context *s = ctx->priv;
>
> -s->flat_range[0] = s->h_fov / 180.f;
> -s->flat_range[1] = s->v_fov / 180.f;
> -
> +s->flat_range[0] = 0.5f * s->h_fov * M_PI / 180.f;
> +s->flat_range[1] = 0.5f * s->v_fov * M_PI / 180.f;
>  return 0;
>  }
>
> @@ -2827,8 +2826,8 @@ static int fisheye_to_xyz(const V360Context *s,
>int i, int j, int width, int height,
>float *vec)
>  {
> -const float uf = s->flat_range[0] * ((2.f * i) / width  - 1.f);
> -const float vf = s->flat_range[1] * ((2.f * j + 1.f) / height - 1.f);
> +const float uf = 2.f * s->flat_range[0] / M_PI * ((2.f * i) / width
> - 1.f);
> +const float vf = 2.f * s->flat_range[1] / M_PI * ((2.f * j + 1.f) /
> height - 1.f);
>
>  const float phi   = atan2f(vf, uf);
>  const float theta = M_PI_2 * (1.f - hypotf(uf, vf));
> @@ -2858,8 +2857,8 @@ static int prepare_fisheye_in(AVFilterContext *ctx)
>  {
>  V360Context *s = ctx->priv;
>
> -s->iflat_range[0] = s->ih_fov / 180.f;
> -s->iflat_range[1] = s->iv_fov / 180.f;
> +s->iflat_range[0] = 0.5f * s->ih_fov * M_PI / 180.f;
> +s->iflat_range[1] = 0.5f * s->iv_fov * M_PI / 180.f;
>
>  return 0;
>  }
> @@ -2882,10 +2881,10 @@ static int xyz_to_fisheye(const V360Context *s,
>  {
>  const float h   = hypotf(vec[0], vec[1]);
>  const float lh  = h > 0.f ? h : 1.f;
> -const float phi = atan2f(h, vec[2]) / M_PI;
> +const float phi = atan2f(h, vec[2]);
>
> -float uf = vec[0] / lh * phi / s->iflat_range[0];
> -float vf = vec[1] / lh * phi / s->iflat_range[1];
> +float uf = 0.5f * vec[0] / lh * phi / s->iflat_range[0];
> +float vf = 0.5f * vec[1] / lh * phi / s->iflat_range[1];
>
>  const int visible = -0.5f < uf && uf < 0.5f && -0.5f < vf && vf <
> 0.5f;
>  int ui, vi;
> --
> 2.31.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] [PATCH 1/2] avformat/utils: add an internal getter function to access AVStream.attached_pic

[James Almer]

It can be removed once the field becomes a pointer.

Signed-off-by: James Almer 
---
 libavformat/apetag.c   |  9 -
 libavformat/asfdec_f.c | 13 +++--
 libavformat/asfdec_o.c | 13 +++--
 libavformat/flac_picture.c | 14 --
 libavformat/hls.c  |  8 +---
 libavformat/id3v2.c| 14 --
 libavformat/internal.h |  2 ++
 libavformat/matroskadec.c  |  2 +-
 libavformat/mov.c  | 19 +++
 libavformat/options.c  | 12 +++-
 libavformat/utils.c| 18 --
 libavformat/wtvdec.c   |  8 +---
 12 files changed, 85 insertions(+), 47 deletions(-)

diff --git a/libavformat/apetag.c b/libavformat/apetag.c
index 454c6c688b..fce0d49c01 100644
--- a/libavformat/apetag.c
+++ b/libavformat/apetag.c
@@ -79,10 +79,10 @@ static int ape_tag_read_field(AVFormatContext *s)
 av_dict_set(&st->metadata, key, filename, 0);
 
 if ((id = ff_guess_image2_codec(filename)) != AV_CODEC_ID_NONE) {
-AVPacket pkt;
+AVPacket *attached_pic = ff_stream_get_attached_pic(st);
 int ret;
 
-ret = av_get_packet(s->pb, &pkt, size);
+ret = av_get_packet(s->pb, attached_pic, size);
 if (ret < 0) {
 av_log(s, AV_LOG_ERROR, "Error reading cover art.\n");
 return ret;
@@ -92,9 +92,8 @@ static int ape_tag_read_field(AVFormatContext *s)
 st->codecpar->codec_type = AVMEDIA_TYPE_VIDEO;
 st->codecpar->codec_id   = id;
 
-st->attached_pic  = pkt;
-st->attached_pic.stream_index = st->index;
-st->attached_pic.flags   |= AV_PKT_FLAG_KEY;
+attached_pic->stream_index = st->index;
+attached_pic->flags   |= AV_PKT_FLAG_KEY;
 } else {
 if ((ret = ff_get_extradata(s, st->codecpar, s->pb, size)) < 0)
 return ret;
diff --git a/libavformat/asfdec_f.c b/libavformat/asfdec_f.c
index 1484b544d9..05b06beb4f 100644
--- a/libavformat/asfdec_f.c
+++ b/libavformat/asfdec_f.c
@@ -223,7 +223,7 @@ static int get_value(AVIOContext *pb, int type, int 
type2_size)
  * but in reality this is only loosely similar */
 static int asf_read_picture(AVFormatContext *s, int len)
 {
-AVPacket pkt  = { 0 };
+AVPacket *attached_pic, *pkt = s->internal->parse_pkt;
 const CodecMime *mime = ff_id3v2_mime_tags;
 enum  AVCodecID id= AV_CODEC_ID_NONE;
 char mimetype[64];
@@ -277,7 +277,7 @@ static int asf_read_picture(AVFormatContext *s, int len)
 return AVERROR(ENOMEM);
 len -= avio_get_str16le(s->pb, len - picsize, desc, desc_len);
 
-ret = av_get_packet(s->pb, &pkt, picsize);
+ret = av_get_packet(s->pb, pkt, picsize);
 if (ret < 0)
 goto fail;
 
@@ -289,9 +289,10 @@ static int asf_read_picture(AVFormatContext *s, int len)
 st->disposition  |= AV_DISPOSITION_ATTACHED_PIC;
 st->codecpar->codec_type  = AVMEDIA_TYPE_VIDEO;
 st->codecpar->codec_id= id;
-st->attached_pic  = pkt;
-st->attached_pic.stream_index = st->index;
-st->attached_pic.flags   |= AV_PKT_FLAG_KEY;
+attached_pic = ff_stream_get_attached_pic(st);
+av_packet_move_ref(attached_pic, pkt);
+attached_pic->stream_index = st->index;
+attached_pic->flags   |= AV_PKT_FLAG_KEY;
 
 if (*desc)
 av_dict_set(&st->metadata, "title", desc, AV_DICT_DONT_STRDUP_VAL);
@@ -304,7 +305,7 @@ static int asf_read_picture(AVFormatContext *s, int len)
 
 fail:
 av_freep(&desc);
-av_packet_unref(&pkt);
+av_packet_unref(pkt);
 return ret;
 }
 
diff --git a/libavformat/asfdec_o.c b/libavformat/asfdec_o.c
index 34ae541934..ac032f98fc 100644
--- a/libavformat/asfdec_o.c
+++ b/libavformat/asfdec_o.c
@@ -360,7 +360,7 @@ static int asf_set_metadata(AVFormatContext *s, const 
uint8_t *name,
  * but in reality this is only loosely similar */
 static int asf_read_picture(AVFormatContext *s, int len)
 {
-AVPacket pkt  = { 0 };
+AVPacket *attached_pic, *pkt = s->internal->parse_pkt;
 const CodecMime *mime = ff_id3v2_mime_tags;
 enum  AVCodecID id= AV_CODEC_ID_NONE;
 char mimetype[64];
@@ -414,7 +414,7 @@ static int asf_read_picture(AVFormatContext *s, int len)
 return AVERROR(ENOMEM);
 len -= avio_get_str16le(s->pb, len - picsize, desc, desc_len);
 
-ret = av_get_packet(s->pb, &pkt, picsize);
+ret = av_get_packet(s->pb, pkt, picsize);
 if (ret < 0)
 goto fail;
 
@@ -427,9 +427,10 @@ static int asf_read_picture(AVFormatContext *s, int len)
 st->disposition  |= AV_DISPOSITION_ATTACHED_PIC;
 st->codecpar->codec_type  = AVMEDIA_TYPE_VIDEO;
 st->codecpar->codec_id= id;
-st->attached_pic  = pkt;
-st->attached_pic.stream_index = st->index;
-st->attached_pic.flags   |= AV_PKT_FLAG_KEY;
+attached_

[FFmpeg-devel] [PATCH 2/2] avformat: add a deprecated attribute to AVStream.attached_pic

[James Almer]

And mention how the field is not being removed but changed, with instructions
for library users to migrate their code.

Signed-off-by: James Almer 
---
 libavformat/avformat.h | 8 
 libavformat/utils.c| 4 
 2 files changed, 12 insertions(+)

diff --git a/libavformat/avformat.h b/libavformat/avformat.h
index 822aa4c631..9fa8049149 100644
--- a/libavformat/avformat.h
+++ b/libavformat/avformat.h
@@ -953,8 +953,16 @@ typedef struct AVStream {
  *
  * decoding: set by libavformat, must not be modified by the caller.
  * encoding: unused
+ *
+ * @deprecated This field will not be removed but become a pointer to an 
AVPacket
+ * owned by libavformat instead.
+ * Callers that want to be forward compatible with future 
libavformat
+ * versions should wrap access to this field with a
+ * LIBAVFORMAT_VERSION_MAJOR preoprocessor check and start 
treating it
+ * as a pointer from version 60 onwards.
  */
 #if FF_API_INIT_PACKET
+attribute_deprecated
 AVPacket attached_pic;
 #else
 AVPacket *attached_pic;
diff --git a/libavformat/utils.c b/libavformat/utils.c
index 3db12af1b6..f7a3b96dab 100644
--- a/libavformat/utils.c
+++ b/libavformat/utils.c
@@ -4384,8 +4384,10 @@ static void free_stream(AVStream **pst)
 av_parser_close(st->parser);
 
 #if FF_API_INIT_PACKET
+FF_DISABLE_DEPRECATION_WARNINGS
 if (st->attached_pic.data)
 av_packet_unref(&st->attached_pic);
+FF_ENABLE_DEPRECATION_WARNINGS
 #else
 av_packet_free(st->attached_pic);
 #endif
@@ -5864,7 +5866,9 @@ FF_ENABLE_DEPRECATION_WARNINGS
 AVPacket *ff_stream_get_attached_pic(AVStream *st)
 {
 #if FF_API_INIT_PACKET
+FF_DISABLE_DEPRECATION_WARNINGS
 return &st->attached_pic;
+FF_ENABLE_DEPRECATION_WARNINGS
 #else
 return st->attached_pic;
 #endif
-- 
2.30.2

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

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

[FFmpeg-devel] GSOC 2021 project "Windows Screen Capture via Desktop Duplication".

[kernel.bin]

Hello everyone!


I'm He Yang, a college student from FuZhou University, China, now major in 
Computer Science. I've been using ffmpeg for years, and I'm interested in 
the 
GSoC idea "Windows Screen Capture via Desktop Duplication".


I've successfully attened GSoC as a student of ReactOS last year, and I've 
been 
writing Win32 code for a long time. I've already found a few trivial bugs 
in 
`libavdevice\gdigrab.c` and send a patch for fixing one of it few days before.


This idea is marked as unmentored projects, so I'd like to ask how can I 
find 
a mentor and get a qualification task, and what to do next.


I would be very glad if a chance was given to me to contribute to FFmpeg.
Thanks!


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

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

Re: [FFmpeg-devel] [PATCH 01/48] avcodec/packet: deprecate av_init_packet()

[Marton Balint]

On Sun, 21 Mar 2021, James Almer wrote:


On 3/21/2021 11:16 AM, Anton Khirnov wrote:

Quoting James Almer (2021-03-21 14:54:22)

On 3/21/2021 9:28 AM, Anton Khirnov wrote:

Quoting James Almer (2021-03-05 17:32:52)

diff --git a/libavformat/avformat.h b/libavformat/avformat.h
index 7da2f3d98e..783cc1b591 100644
--- a/libavformat/avformat.h
+++ b/libavformat/avformat.h
@@ -954,7 +954,11 @@ typedef struct AVStream {
* decoding: set by libavformat, must not be modified by the 

caller.

* encoding: unused
*/
+#if FF_API_INIT_PACKET
   AVPacket attached_pic;
+#else
+AVPacket *attached_pic;
+#endif


Sorry I'm late to the party, but as we are changing the type of an
existing field, we need to explicitly spell out a way for the callers to
make their code forward compatible. E.g. similarly to what I made for
thread_safe_callbacks deprecation.


What do you suggest? The field is not printing deprecation warnings, so
would a doxy comment be enough for people to notice it?
Have we done a similar change before? I know at least for symbols like
public functions we never change their signature in an incompatible way,
and instead replace them altogether.

Maybe we could add the deprecated attribute to attached_pic, introduce a
temporary getter function that returns a pointer to the packet, mention
in the doxy that the field is not going away, is just changing types,
and they have the option of using the getter for a fire-and-forget
migration process, then maybe deprecate and eventually remove the getter
after the switch is done.


This seems like a lot of hoops to jump through. Wouldn't it then be
better to just add a new field with a new name?


A name change just because it's now a pointer seems overkill.


I don't think it is. A name change guarantees that existing code won't 
compile to something that will surely crash. IMHO the clean solution is to 
keep the old field with deprecation, and add a new field. Same what I did 
with AVFormat->filename / AVFormat->url.


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

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

[FFmpeg-devel] URLs or not URLs (was: 01/48] avcodec/packet: deprecate) av_init_packet()

[Nicolas George]

Marton Balint (12021-03-21):
> Same what I did with AVFormat->filename / AVFormat->url.

By the way, about that: at some point, we will need to clarify what part
of our API uses real URLs and what parts uses fake URLs.

Because as it is, a lot of code looks like it uses URLs but really it
does not. The worst offender is "file:" it looks like an URL, the prefix
is a 100% standard URL scheme. Yet, it will not find
file:///home/user/Some%20Movie.mkv because it does not obey to the
standard syntax of file:// URLs.

I had the vague intent of proposing a migration path, but never time to
work on it. It involves:

1. Introduce the fs: protocol as a synonym for file:.

2. For some time, detect if the behavior is likely to change in the next
   step and warn the user.

3. Detect file:// and treat it like a standard file:// URL, including
   skipping the server, query and fragment part and performing
   %-unescaping; keep file: without the double slash as an alias for
   fs:.

4. For some more time, warn users if they are using file: but not
   file://.

5. Remove the compatibility file: → fs: alias.

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 01/48] avcodec/packet: deprecate av_init_packet()

[James Almer]

On 3/21/2021 3:15 PM, Marton Balint wrote:



On Sun, 21 Mar 2021, James Almer wrote:


On 3/21/2021 11:16 AM, Anton Khirnov wrote:

Quoting James Almer (2021-03-21 14:54:22)

On 3/21/2021 9:28 AM, Anton Khirnov wrote:

Quoting James Almer (2021-03-05 17:32:52)

diff --git a/libavformat/avformat.h b/libavformat/avformat.h
index 7da2f3d98e..783cc1b591 100644
--- a/libavformat/avformat.h
+++ b/libavformat/avformat.h
@@ -954,7 +954,11 @@ typedef struct AVStream {
    * decoding: set by libavformat, must not be modified by the 

caller.

    * encoding: unused
    */
+#if FF_API_INIT_PACKET
   AVPacket attached_pic;
+#else
+    AVPacket *attached_pic;
+#endif


Sorry I'm late to the party, but as we are changing the type of an
existing field, we need to explicitly spell out a way for the 
callers to

make their code forward compatible. E.g. similarly to what I made for
thread_safe_callbacks deprecation.


What do you suggest? The field is not printing deprecation warnings, so
would a doxy comment be enough for people to notice it?
Have we done a similar change before? I know at least for symbols like
public functions we never change their signature in an incompatible 
way,

and instead replace them altogether.

Maybe we could add the deprecated attribute to attached_pic, 
introduce a

temporary getter function that returns a pointer to the packet, mention
in the doxy that the field is not going away, is just changing types,
and they have the option of using the getter for a fire-and-forget
migration process, then maybe deprecate and eventually remove the 
getter

after the switch is done.


This seems like a lot of hoops to jump through. Wouldn't it then be
better to just add a new field with a new name?


A name change just because it's now a pointer seems overkill.


I don't think it is. A name change guarantees that existing code won't 
compile to something that will surely crash. IMHO the clean solution is 
to keep the old field with deprecation, and add a new field. Same what I 
did with AVFormat->filename / AVFormat->url.


Compilation will fail if your code doesn't treat the field as a pointer 
after the switch, printing something like


error: 'st->attached_pic' is a pointer; did you mean to use '->'?
  123 | st->attached_pic.flags |= AV_PKT_FLAG_KEY;
  | ^

So it's not like it will compile and then crash at runtime by accessing 
the wrong thing.


But if you still feel more inclined to replace the field, can you 
suggest a name for the new one?

___
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] URLs or not URLs (was: 01/48] avcodec/packet: deprecate) av_init_packet()

[Nicolas George]

Nicolas George (12021-03-21):
> By the way, about that: at some point, we will need to clarify what part
> of our API uses real URLs and what parts uses fake URLs.
> 
> Because as it is, a lot of code looks like it uses URLs but really it
> does not. The worst offender is "file:" it looks like an URL, the prefix
> is a 100% standard URL scheme. Yet, it will not find
> file:///home/user/Some%20Movie.mkv because it does not obey to the
> standard syntax of file:// URLs.

This is now Trac ticket #9157:

https://trac.ffmpeg.org/ticket/9157

Note that it is a rather simple task for somebody who wants to get
involved in the project.

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 1/2] avformat/utils: add an internal getter function to access AVStream.attached_pic

[James Almer]

On 3/21/2021 2:08 PM, James Almer wrote:

diff --git a/libavformat/options.c b/libavformat/options.c
index 07403b533e..bd4056caa1 100644
--- a/libavformat/options.c
+++ b/libavformat/options.c
@@ -220,11 +220,21 @@ AVFormatContext *avformat_alloc_context(void)
  av_free(ic);
  return NULL;
  }
+#if !FF_API_INIT_PACKET
+ic->attached_pic = av_packet_alloc();
+#endif
  internal->pkt = av_packet_alloc();
  internal->parse_pkt = av_packet_alloc();
-if (!internal->pkt || !internal->parse_pkt) {
+if (!internal->pkt || !internal->parse_pkt
+#if !FF_API_INIT_PACKET
+|| !ic->attached_pic
+#endif
+) {
  av_packet_free(&internal->pkt);
  av_packet_free(&internal->parse_pkt);
+#if !FF_API_INIT_PACKET
+av_packet_free(&ic->attached_pic);
+#endif
  av_free(internal);
  av_free(ic);
  return NULL;


Disregard this patch, since this chunk obviously does not compile. Not 
sure why i didn't notice it.

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

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

Re: [FFmpeg-devel] [PATCH 01/48] avcodec/packet: deprecate av_init_packet()

[James Almer]

On 3/21/2021 3:37 PM, James Almer wrote:

On 3/21/2021 3:15 PM, Marton Balint wrote:



On Sun, 21 Mar 2021, James Almer wrote:


On 3/21/2021 11:16 AM, Anton Khirnov wrote:

Quoting James Almer (2021-03-21 14:54:22)

On 3/21/2021 9:28 AM, Anton Khirnov wrote:

Quoting James Almer (2021-03-05 17:32:52)

diff --git a/libavformat/avformat.h b/libavformat/avformat.h
index 7da2f3d98e..783cc1b591 100644
--- a/libavformat/avformat.h
+++ b/libavformat/avformat.h
@@ -954,7 +954,11 @@ typedef struct AVStream {
    * decoding: set by libavformat, must not be modified by the 

caller.

    * encoding: unused
    */
+#if FF_API_INIT_PACKET
   AVPacket attached_pic;
+#else
+    AVPacket *attached_pic;
+#endif


Sorry I'm late to the party, but as we are changing the type of an
existing field, we need to explicitly spell out a way for the 
callers to

make their code forward compatible. E.g. similarly to what I made for
thread_safe_callbacks deprecation.


What do you suggest? The field is not printing deprecation 
warnings, so

would a doxy comment be enough for people to notice it?
Have we done a similar change before? I know at least for symbols like
public functions we never change their signature in an incompatible 
way,

and instead replace them altogether.

Maybe we could add the deprecated attribute to attached_pic, 
introduce a
temporary getter function that returns a pointer to the packet, 
mention

in the doxy that the field is not going away, is just changing types,
and they have the option of using the getter for a fire-and-forget
migration process, then maybe deprecate and eventually remove the 
getter

after the switch is done.


This seems like a lot of hoops to jump through. Wouldn't it then be
better to just add a new field with a new name?


A name change just because it's now a pointer seems overkill.


I don't think it is. A name change guarantees that existing code won't 
compile to something that will surely crash. IMHO the clean solution 
is to keep the old field with deprecation, and add a new field. Same 
what I did with AVFormat->filename / AVFormat->url.


Compilation will fail if your code doesn't treat the field as a pointer 
after the switch, printing something like


error: 'st->attached_pic' is a pointer; did you mean to use '->'?
   123 | st->attached_pic.flags |= AV_PKT_FLAG_KEY;
   | ^

So it's not like it will compile and then crash at runtime by accessing 
the wrong thing.


But if you still feel more inclined to replace the field, can you 
suggest a name for the new one?


Also, i wont be able to add a new field until after the bump because of 
the libavdevice franken-ABI situation.

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

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

Re: [FFmpeg-devel] [PATCH 01/48] avcodec/packet: deprecate av_init_packet()

[James Almer]

On 3/21/2021 3:37 PM, James Almer wrote:

On 3/21/2021 3:15 PM, Marton Balint wrote:



On Sun, 21 Mar 2021, James Almer wrote:


On 3/21/2021 11:16 AM, Anton Khirnov wrote:

Quoting James Almer (2021-03-21 14:54:22)

On 3/21/2021 9:28 AM, Anton Khirnov wrote:

Quoting James Almer (2021-03-05 17:32:52)

diff --git a/libavformat/avformat.h b/libavformat/avformat.h
index 7da2f3d98e..783cc1b591 100644
--- a/libavformat/avformat.h
+++ b/libavformat/avformat.h
@@ -954,7 +954,11 @@ typedef struct AVStream {
    * decoding: set by libavformat, must not be modified by the 

caller.

    * encoding: unused
    */
+#if FF_API_INIT_PACKET
   AVPacket attached_pic;
+#else
+    AVPacket *attached_pic;
+#endif


Sorry I'm late to the party, but as we are changing the type of an
existing field, we need to explicitly spell out a way for the 
callers to

make their code forward compatible. E.g. similarly to what I made for
thread_safe_callbacks deprecation.


What do you suggest? The field is not printing deprecation 
warnings, so

would a doxy comment be enough for people to notice it?
Have we done a similar change before? I know at least for symbols like
public functions we never change their signature in an incompatible 
way,

and instead replace them altogether.

Maybe we could add the deprecated attribute to attached_pic, 
introduce a
temporary getter function that returns a pointer to the packet, 
mention

in the doxy that the field is not going away, is just changing types,
and they have the option of using the getter for a fire-and-forget
migration process, then maybe deprecate and eventually remove the 
getter

after the switch is done.


This seems like a lot of hoops to jump through. Wouldn't it then be
better to just add a new field with a new name?


A name change just because it's now a pointer seems overkill.


I don't think it is. A name change guarantees that existing code won't 
compile to something that will surely crash. IMHO the clean solution 
is to keep the old field with deprecation, and add a new field. Same 
what I did with AVFormat->filename / AVFormat->url.


Compilation will fail if your code doesn't treat the field as a pointer 
after the switch, printing something like


error: 'st->attached_pic' is a pointer; did you mean to use '->'?
   123 | st->attached_pic.flags |= AV_PKT_FLAG_KEY;
   | ^

So it's not like it will compile and then crash at runtime by accessing 
the wrong thing.


After looking a bit more, it will fail if you try to access fields like 
i mentioned above, but if you pass it as argument to some function it 
will only warn about mismatching types.


So i guess yeah, a new field with a new name would be the cleanest 
solution. So as i said, field name suggestions welcome.




But if you still feel more inclined to replace the field, can you 
suggest a name for the new one?


___
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 06/18] avformat/apetag: Avoid stack packet when reading attached picture

[Andreas Rheinhardt]

Andreas Rheinhardt:
> Read it directly into AVStream.attached_pic.
> 
> Signed-off-by: Andreas Rheinhardt 
> ---
>  libavformat/apetag.c | 4 +---
>  1 file changed, 1 insertion(+), 3 deletions(-)
> 
> diff --git a/libavformat/apetag.c b/libavformat/apetag.c
> index 454c6c688b..23ee6b516d 100644
> --- a/libavformat/apetag.c
> +++ b/libavformat/apetag.c
> @@ -79,10 +79,9 @@ static int ape_tag_read_field(AVFormatContext *s)
>  av_dict_set(&st->metadata, key, filename, 0);
>  
>  if ((id = ff_guess_image2_codec(filename)) != AV_CODEC_ID_NONE) {
> -AVPacket pkt;
>  int ret;
>  
> -ret = av_get_packet(s->pb, &pkt, size);
> +ret = av_get_packet(s->pb, &st->attached_pic, size);
>  if (ret < 0) {
>  av_log(s, AV_LOG_ERROR, "Error reading cover art.\n");
>  return ret;
> @@ -92,7 +91,6 @@ static int ape_tag_read_field(AVFormatContext *s)
>  st->codecpar->codec_type = AVMEDIA_TYPE_VIDEO;
>  st->codecpar->codec_id   = id;
>  
> -st->attached_pic  = pkt;
>  st->attached_pic.stream_index = st->index;
>  st->attached_pic.flags   |= AV_PKT_FLAG_KEY;
>  } else {
> 
Will apply.

- 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 2/5] avcodec/avcodec: Don't use NULL for %s printf specifier

[Andreas Rheinhardt]

Andreas Rheinhardt:
> Our "get name" functions can return NULL for invalid/unknown
> arguments. So check for this.
> 
> Signed-off-by: Andreas Rheinhardt 
> ---
> av_get_colorspace_name() can even return NULL for supported colorspaces.
> 
>  libavcodec/avcodec.c | 33 +
>  1 file changed, 17 insertions(+), 16 deletions(-)
> 
> diff --git a/libavcodec/avcodec.c b/libavcodec/avcodec.c
> index 3088d2ff3f..93383dc9fb 100644
> --- a/libavcodec/avcodec.c
> +++ b/libavcodec/avcodec.c
> @@ -607,6 +607,7 @@ void avcodec_string(char *buf, int buf_size, 
> AVCodecContext *enc, int encode)
>  int new_line = 0;
>  AVRational display_aspect_ratio;
>  const char *separator = enc->dump_separator ? (const char 
> *)enc->dump_separator : ", ";
> +const char *str;
>  
>  if (!buf || buf_size <= 0)
>  return;
> @@ -642,14 +643,14 @@ void avcodec_string(char *buf, int buf_size, 
> AVCodecContext *enc, int encode)
>  av_strlcat(buf, separator, buf_size);
>  
>  snprintf(buf + strlen(buf), buf_size - strlen(buf),
> - "%s", enc->pix_fmt == AV_PIX_FMT_NONE ? "none" :
> - av_get_pix_fmt_name(enc->pix_fmt));
> + "%s", enc->pix_fmt == AV_PIX_FMT_NONE ? "none" :
> + av_x_if_null(av_get_pix_fmt_name(enc->pix_fmt), 
> "unknown"));
>  if (enc->bits_per_raw_sample && enc->pix_fmt != AV_PIX_FMT_NONE 
> &&
>  enc->bits_per_raw_sample < 
> av_pix_fmt_desc_get(enc->pix_fmt)->comp[0].depth)
>  av_strlcatf(detail, sizeof(detail), "%d bpc, ", 
> enc->bits_per_raw_sample);
> -if (enc->color_range != AVCOL_RANGE_UNSPECIFIED)
> -av_strlcatf(detail, sizeof(detail), "%s, ",
> -av_color_range_name(enc->color_range));
> +if (enc->color_range != AVCOL_RANGE_UNSPECIFIED &&
> +(str = av_color_range_name(enc->color_range)))
> +av_strlcatf(detail, sizeof(detail), "%s, ", str);
>  
>  if (enc->colorspace != AVCOL_SPC_UNSPECIFIED ||
>  enc->color_primaries != AVCOL_PRI_UNSPECIFIED ||
> @@ -658,12 +659,11 @@ void avcodec_string(char *buf, int buf_size, 
> AVCodecContext *enc, int encode)
>  enc->colorspace != (int)enc->color_trc) {
>  new_line = 1;
>  av_strlcatf(detail, sizeof(detail), "%s/%s/%s, ",
> -av_color_space_name(enc->colorspace),
> -
> av_color_primaries_name(enc->color_primaries),
> -av_color_transfer_name(enc->color_trc));
> -} else
> -av_strlcatf(detail, sizeof(detail), "%s, ",
> -av_get_colorspace_name(enc->colorspace));
> +
> av_x_if_null(av_color_space_name(enc->colorspace), "unknown"),
> +
> av_x_if_null(av_color_primaries_name(enc->color_primaries), "unknown"),
> +
> av_x_if_null(av_color_transfer_name(enc->color_trc), "unkown"));

av_x_if_null() returns a pointer to void and so the compiler gave me
warnings for the above lines, because it expected a pointer to char. Yet
I ignored them, because I use the -pedantic flag for compilations, so I
am used to getting warnings if the pointer corresponding to %p is
something else than a pointer to void. Turns out this is not only a
pedantic thing, so I replaced av_x_if_null() by a static function
unknown_if_null() here that is completely type-safe.
This also fixed the "unkown" typo above.

> + } else if (str = av_get_colorspace_name(enc->colorspace))
> +   av_strlcatf(detail, sizeof(detail), "%s, ", str);
>  }
>  
>  if (enc->field_order != AV_FIELD_UNKNOWN) {
> @@ -681,9 +681,9 @@ void avcodec_string(char *buf, int buf_size, 
> AVCodecContext *enc, int encode)
>  }
>  
>  if (av_log_get_level() >= AV_LOG_VERBOSE &&
> -enc->chroma_sample_location != AVCHROMA_LOC_UNSPECIFIED)
> -av_strlcatf(detail, sizeof(detail), "%s, ",
> -
> av_chroma_location_name(enc->chroma_sample_location));
> +enc->chroma_sample_location != AVCHROMA_LOC_UNSPECIFIED &&
> +(str = av_chroma_location_name(enc->chroma_sample_location)))
> +av_strlcatf(detail, sizeof(detail), "%s, ", str);
>  
>  if (strlen(detail) > 1) {
>  detail[strlen(detail) - 2] = 0;
> @@ -741,9 +741,10 @@ void avcodec_string(char *buf, int buf_size, 
> AVCodecContext *enc, int encode)
>   "%d Hz, ", enc->sample_rate);
>  }
>  av_get_channel_layout_string(buf + strlen(buf), buf_size - 
> strlen(buf), enc->channels, enc->channel_layout);
> -if (enc->sample_fmt != 

Re: [FFmpeg-devel] [PATCH 01/48] avcodec/packet: deprecate av_init_packet()

[Marton Balint]

On Sun, 21 Mar 2021, James Almer wrote:


On 3/21/2021 3:37 PM, James Almer wrote:

On 3/21/2021 3:15 PM, Marton Balint wrote:



On Sun, 21 Mar 2021, James Almer wrote:


On 3/21/2021 11:16 AM, Anton Khirnov wrote:

Quoting James Almer (2021-03-21 14:54:22)

On 3/21/2021 9:28 AM, Anton Khirnov wrote:

Quoting James Almer (2021-03-05 17:32:52)

diff --git a/libavformat/avformat.h b/libavformat/avformat.h
index 7da2f3d98e..783cc1b591 100644
--- a/libavformat/avformat.h
+++ b/libavformat/avformat.h
@@ -954,7 +954,11 @@ typedef struct AVStream {
    * decoding: set by libavformat, must not be modified by the 

caller.

    * encoding: unused
    */
+#if FF_API_INIT_PACKET
   AVPacket attached_pic;
+#else
+    AVPacket *attached_pic;
+#endif


Sorry I'm late to the party, but as we are changing the type of an
existing field, we need to explicitly spell out a way for the 
callers to

make their code forward compatible. E.g. similarly to what I made for
thread_safe_callbacks deprecation.


What do you suggest? The field is not printing deprecation 
warnings, so

would a doxy comment be enough for people to notice it?
Have we done a similar change before? I know at least for symbols like
public functions we never change their signature in an incompatible 
way,

and instead replace them altogether.

Maybe we could add the deprecated attribute to attached_pic, 
introduce a
temporary getter function that returns a pointer to the packet, 
mention

in the doxy that the field is not going away, is just changing types,
and they have the option of using the getter for a fire-and-forget
migration process, then maybe deprecate and eventually remove the 
getter

after the switch is done.


This seems like a lot of hoops to jump through. Wouldn't it then be
better to just add a new field with a new name?


A name change just because it's now a pointer seems overkill.


I don't think it is. A name change guarantees that existing code won't 
compile to something that will surely crash. IMHO the clean solution 
is to keep the old field with deprecation, and add a new field. Same 
what I did with AVFormat->filename / AVFormat->url.


Compilation will fail if your code doesn't treat the field as a pointer 
after the switch, printing something like


error: 'st->attached_pic' is a pointer; did you mean to use '->'?
   123 | st->attached_pic.flags |= AV_PKT_FLAG_KEY;
   | ^

So it's not like it will compile and then crash at runtime by accessing 
the wrong thing.


After looking a bit more, it will fail if you try to access fields like 
i mentioned above, but if you pass it as argument to some function it 
will only warn about mismatching types.


So i guess yeah, a new field with a new name would be the cleanest 
solution. So as i said, field name suggestions welcome.


attached_pic_pkt or attached_pkt maybe.

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

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

[FFmpeg-devel] [PATCH v2] avcodec: Factor updating palette out

[Andreas Rheinhardt]

Because the properties of frames returned from ff_get/reget_buffer
are not reset at all, lots of returned frames had palette_has_changed
wrongly set to 1. This has been changed, too.

Signed-off-by: Andreas Rheinhardt 
---
Moved it to decode.h as requested.

 libavcodec/8bps.c   | 12 ++--
 libavcodec/cinepak.c| 10 ++
 libavcodec/decode.c | 14 ++
 libavcodec/decode.h |  9 +
 libavcodec/gdv.c|  6 ++
 libavcodec/idcinvideo.c | 10 ++
 libavcodec/imx.c|  6 ++
 libavcodec/interplayvideo.c | 10 ++
 libavcodec/kmvc.c   |  9 ++---
 libavcodec/msrle.c  | 12 +++-
 libavcodec/msvideo1.c   | 11 ++-
 libavcodec/qpeg.c   | 10 ++
 libavcodec/qtrle.c  | 10 +-
 libavcodec/rawdec.c | 13 ++---
 libavcodec/rscc.c   | 14 +++---
 libavcodec/smc.c| 10 ++
 libavcodec/tscc.c   | 11 ++-
 17 files changed, 54 insertions(+), 123 deletions(-)

diff --git a/libavcodec/8bps.c b/libavcodec/8bps.c
index 53e939d35d..dda8b8b1c9 100644
--- a/libavcodec/8bps.c
+++ b/libavcodec/8bps.c
@@ -37,6 +37,7 @@
 #include "libavutil/internal.h"
 #include "libavutil/intreadwrite.h"
 #include "avcodec.h"
+#include "decode.h"
 #include "internal.h"
 
 
@@ -122,16 +123,7 @@ static int decode_frame(AVCodecContext *avctx, void *data,
 }
 
 if (avctx->bits_per_coded_sample <= 8) {
-buffer_size_t size;
-const uint8_t *pal = av_packet_get_side_data(avpkt,
- AV_PKT_DATA_PALETTE,
- &size);
-if (pal && size == AVPALETTE_SIZE) {
-frame->palette_has_changed = 1;
-memcpy(c->pal, pal, AVPALETTE_SIZE);
-} else if (pal) {
-av_log(avctx, AV_LOG_ERROR, "Palette size %d is wrong\n", size);
-}
+frame->palette_has_changed = ff_copy_palette(c->pal, avpkt, avctx);
 
 memcpy (frame->data[1], c->pal, AVPALETTE_SIZE);
 }
diff --git a/libavcodec/cinepak.c b/libavcodec/cinepak.c
index d70cb4b694..ccd6af3208 100644
--- a/libavcodec/cinepak.c
+++ b/libavcodec/cinepak.c
@@ -40,6 +40,7 @@
 #include "libavutil/common.h"
 #include "libavutil/intreadwrite.h"
 #include "avcodec.h"
+#include "decode.h"
 #include "internal.h"
 
 
@@ -477,14 +478,7 @@ static int cinepak_decode_frame(AVCodecContext *avctx,
 return ret;
 
 if (s->palette_video) {
-buffer_size_t size;
-const uint8_t *pal = av_packet_get_side_data(avpkt, 
AV_PKT_DATA_PALETTE, &size);
-if (pal && size == AVPALETTE_SIZE) {
-s->frame->palette_has_changed = 1;
-memcpy(s->pal, pal, AVPALETTE_SIZE);
-} else if (pal) {
-av_log(avctx, AV_LOG_ERROR, "Palette size %d is wrong\n", size);
-}
+s->frame->palette_has_changed = ff_copy_palette(s->pal, avpkt, avctx);
 }
 
 if ((ret = cinepak_decode(s)) < 0) {
diff --git a/libavcodec/decode.c b/libavcodec/decode.c
index 390147908d..0956a6ac6f 100644
--- a/libavcodec/decode.c
+++ b/libavcodec/decode.c
@@ -2091,3 +2091,17 @@ FF_ENABLE_DEPRECATION_WARNINGS
 
 return 0;
 }
+
+int ff_copy_palette(void *dst, const AVPacket *src, void *logctx)
+{
+buffer_size_t size;
+const void *pal = av_packet_get_side_data(src, AV_PKT_DATA_PALETTE, &size);
+
+if (pal && size == AVPALETTE_SIZE) {
+memcpy(dst, pal, AVPALETTE_SIZE);
+return 1;
+} else if (pal) {
+av_log(logctx, AV_LOG_ERROR, "Palette size %d is wrong\n", size);
+}
+return 0;
+}
diff --git a/libavcodec/decode.h b/libavcodec/decode.h
index 1467b1eb33..dee2543b1c 100644
--- a/libavcodec/decode.h
+++ b/libavcodec/decode.h
@@ -79,6 +79,15 @@ int ff_decode_get_hw_frames_ctx(AVCodecContext *avctx,
 
 int ff_attach_decode_data(AVFrame *frame);
 
+/**
+ * Check whether the side-data of src contains a palette of
+ * size AVPALETTE_SIZE; if so, copy it to dst and return 1;
+ * else return 0.
+ * Also emit an error message upon encountering a palette
+ * with invalid size.
+ */
+int ff_copy_palette(void *dst, const AVPacket *src, void *logctx);
+
 /**
  * Perform decoder initialization and validation.
  * Called when opening the decoder, before the AVCodec.init() call.
diff --git a/libavcodec/gdv.c b/libavcodec/gdv.c
index 860634c9ec..406d79df01 100644
--- a/libavcodec/gdv.c
+++ b/libavcodec/gdv.c
@@ -23,6 +23,7 @@
 #include "libavutil/common.h"
 #include "avcodec.h"
 #include "bytestream.h"
+#include "decode.h"
 #include "internal.h"
 
 typedef struct GDVContext {
@@ -462,8 +463,6 @@ static int gdv_decode_frame(AVCodecContext *avctx, void 
*data,
 PutByteContext *pb = &gdv->pb;
 AVFrame *frame = data;
 int ret, i;
-buffer_size_t pal_size;
-const uint8_t *pal = av_packet_get_side_data(avpkt, AV_PKT_DATA_PALETTE, 
&pal_size);
 int co

[FFmpeg-devel] [PATCH] avfilter/vf_nlmeans_opencl: 16-bit depth compatibility

[Lucas Clemente Vella]

I do not recommend this patch for inclusion in master.

I used this implementation to quantify the floating pointing error
introduced by my next patch, which I think is better suited for
general usage, because the it is much faster and the error is
very small.

Adds 16-bit depth compatibility to the filter, at the cost
of being twice as slower.

Signed-off-by: Lucas Clemente Vella 
---
 libavfilter/opencl/nlmeans.cl   | 28 ++--
 libavfilter/vf_nlmeans_opencl.c |  6 ++
 2 files changed, 16 insertions(+), 18 deletions(-)

diff --git a/libavfilter/opencl/nlmeans.cl b/libavfilter/opencl/nlmeans.cl
index 72bd681fd6..69e630d9fc 100644
--- a/libavfilter/opencl/nlmeans.cl
+++ b/libavfilter/opencl/nlmeans.cl
@@ -20,7 +20,7 @@ const sampler_t sampler = (CLK_NORMALIZED_COORDS_FALSE |
CLK_ADDRESS_CLAMP_TO_EDGE   |
CLK_FILTER_NEAREST);
 
-kernel void horiz_sum(__global uint4 *integral_img,
+kernel void horiz_sum(__global ulong4 *integral_img,
   __read_only image2d_t src,
   int width,
   int height,
@@ -31,7 +31,7 @@ kernel void horiz_sum(__global uint4 *integral_img,
 int y = get_global_id(0);
 int work_size = get_global_size(0);
 
-uint4 sum = (uint4)(0);
+ulong4 sum = (ulong4)(0);
 float4 s2;
 for (int i = 0; i < width; i++) {
 float s1 = read_imagef(src, sampler, (int2)(i, y)).x;
@@ -39,20 +39,20 @@ kernel void horiz_sum(__global uint4 *integral_img,
 s2.y = read_imagef(src, sampler, (int2)(i + dx.y, y + dy.y)).x;
 s2.z = read_imagef(src, sampler, (int2)(i + dx.z, y + dy.z)).x;
 s2.w = read_imagef(src, sampler, (int2)(i + dx.w, y + dy.w)).x;
-sum += convert_uint4((s1 - s2) * (s1 - s2) * 255 * 255);
+sum += convert_ulong4((s1 - s2) * (s1 - s2) * 65535 * 65535);
 integral_img[y * width + i] = sum;
 }
 }
 
-kernel void vert_sum(__global uint4 *integral_img,
+kernel void vert_sum(__global ulong4 *integral_img,
  __global int *overflow,
  int width,
  int height)
 {
 int x = get_global_id(0);
-uint4 sum = 0;
+ulong4 sum = 0;
 for (int i = 0; i < height; i++) {
-if (any((uint4)UINT_MAX - integral_img[i * width + x] < sum))
+if (any((ulong4)ULONG_MAX - integral_img[i * width + x] < sum))
 atomic_inc(overflow);
 integral_img[i * width + x] += sum;
 sum = integral_img[i * width + x];
@@ -60,7 +60,7 @@ kernel void vert_sum(__global uint4 *integral_img,
 }
 
 kernel void weight_accum(global float *sum, global float *weight,
- global uint4 *integral_img, __read_only image2d_t src,
+ global ulong4 *integral_img, __read_only image2d_t 
src,
  int width, int height, int p, float h,
  int4 dx, int4 dy)
 {
@@ -75,16 +75,16 @@ kernel void weight_accum(global float *sum, global float 
*weight,
 int y = get_global_id(1);
 int4 xoff = x + dx;
 int4 yoff = y + dy;
-uint4 a = 0, b = 0, c = 0, d = 0;
+ulong4 a = 0, b = 0, c = 0, d = 0;
 uint4 src_pix = 0;
 
 // out-of-bounding-box?
 int oobb = (x - p) < 0 || (y - p) < 0 || (y + p) >= height || (x + p) >= 
width;
 
-src_pix.x = (int)(255 * read_imagef(src, sampler, (int2)(xoff.x, 
yoff.x)).x);
-src_pix.y = (int)(255 * read_imagef(src, sampler, (int2)(xoff.y, 
yoff.y)).x);
-src_pix.z = (int)(255 * read_imagef(src, sampler, (int2)(xoff.z, 
yoff.z)).x);
-src_pix.w = (int)(255 * read_imagef(src, sampler, (int2)(xoff.w, 
yoff.w)).x);
+src_pix.x = (int)(65535 * read_imagef(src, sampler, (int2)(xoff.x, 
yoff.x)).x);
+src_pix.y = (int)(65535 * read_imagef(src, sampler, (int2)(xoff.y, 
yoff.y)).x);
+src_pix.z = (int)(65535 * read_imagef(src, sampler, (int2)(xoff.z, 
yoff.z)).x);
+src_pix.w = (int)(65535 * read_imagef(src, sampler, (int2)(xoff.w, 
yoff.w)).x);
 if (!oobb) {
 a = integral_img[(y - p) * width + x - p];
 b = integral_img[(y + p) * width + x - p];
@@ -93,7 +93,7 @@ kernel void weight_accum(global float *sum, global float 
*weight,
 }
 
 float4 patch_diff = convert_float4(d + a - c - b);
-float4 w = native_exp(-patch_diff / (h * h));
+float4 w = native_exp(-patch_diff * (float4)1.5140274644582053e-05 / (h * 
h));
 float w_sum = w.x + w.y + w.z + w.w;
 weight[y * width + x] += w_sum;
 sum[y * width + x] += dot(w, convert_float4(src_pix));
@@ -109,7 +109,7 @@ kernel void average(__write_only image2d_t dst,
 float w = weight[y * dim.x + x];
 float s = sum[y * dim.x + x];
 float src_pix = read_imagef(src, sampler, (int2)(x, y)).x;
-float r = (s + src_pix * 255) / (1.0f + w) / 255.0f;
+float r = (s + src_pix * 65535) / (1.0f + w) / 65535.0f;
 if (x < dim.x && y < dim.y)
 write_imagef(dst, (int2)(x, y), (float4)(r, 

Re: [FFmpeg-devel] [PATCH 01/48] avcodec/packet: deprecate av_init_packet()

[Hendrik Leppkes]

On Sun, Mar 21, 2021 at 3:24 PM James Almer  wrote:
>
> How about adding the deprecation attribute to prompt people to read the
> doxy, where we state the field is not going away, just changing types?
> Otherwise i don't think people will notice.

I really don't like such solutions. You get warning spam in user code
with basically no way to remedy them.

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

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

[FFmpeg-devel] [PATCH] avfilter/vf_nlmeans_opencl: making filter independent of bit depth

[Lucas Clemente Vella]

This filter originally quantized OpenCL float images fetchs in 256 levels,
and computed the integral image of squared differences in 32 bit integers.

This had two consequences:
1) it could overflow if the image resolution was big enough (I got overflows
in a 4K video);
2) it dropped precision from bit depths higher than 8 bits.

Now the integral image is computed with float values in range [0, 1], instead
of integers in range [0, 255] (then squared), so there is no longer the risk
of overflow.

And even with the accumulated floating point error over the integral image,
the resulting difference between this float implementation and an experimental
uint64 implementation with 65535 quantization levels is less than 0.08%
on the worst difference (per component), and less than 0.002% on average. For
reference, the smallest variation possible on a 10-bit quantization is 0.098%
of the total intensity. This was tested on a 4K frame from an 10-bit source.

Signed-off-by: Lucas Clemente Vella 
---
 libavfilter/opencl/nlmeans.cl   | 31 ++
 libavfilter/vf_nlmeans_opencl.c | 34 +
 2 files changed, 19 insertions(+), 46 deletions(-)

diff --git a/libavfilter/opencl/nlmeans.cl b/libavfilter/opencl/nlmeans.cl
index 72bd681fd6..6d78a41e46 100644
--- a/libavfilter/opencl/nlmeans.cl
+++ b/libavfilter/opencl/nlmeans.cl
@@ -20,7 +20,7 @@ const sampler_t sampler = (CLK_NORMALIZED_COORDS_FALSE |
CLK_ADDRESS_CLAMP_TO_EDGE   |
CLK_FILTER_NEAREST);
 
-kernel void horiz_sum(__global uint4 *integral_img,
+kernel void horiz_sum(__global float4 *integral_img,
   __read_only image2d_t src,
   int width,
   int height,
@@ -31,7 +31,7 @@ kernel void horiz_sum(__global uint4 *integral_img,
 int y = get_global_id(0);
 int work_size = get_global_size(0);
 
-uint4 sum = (uint4)(0);
+float4 sum = 0.0;
 float4 s2;
 for (int i = 0; i < width; i++) {
 float s1 = read_imagef(src, sampler, (int2)(i, y)).x;
@@ -39,28 +39,25 @@ kernel void horiz_sum(__global uint4 *integral_img,
 s2.y = read_imagef(src, sampler, (int2)(i + dx.y, y + dy.y)).x;
 s2.z = read_imagef(src, sampler, (int2)(i + dx.z, y + dy.z)).x;
 s2.w = read_imagef(src, sampler, (int2)(i + dx.w, y + dy.w)).x;
-sum += convert_uint4((s1 - s2) * (s1 - s2) * 255 * 255);
+sum += (s1 - s2) * (s1 - s2);
 integral_img[y * width + i] = sum;
 }
 }
 
-kernel void vert_sum(__global uint4 *integral_img,
- __global int *overflow,
+kernel void vert_sum(__global float4 *integral_img,
  int width,
  int height)
 {
 int x = get_global_id(0);
-uint4 sum = 0;
+float4 sum = 0;
 for (int i = 0; i < height; i++) {
-if (any((uint4)UINT_MAX - integral_img[i * width + x] < sum))
-atomic_inc(overflow);
 integral_img[i * width + x] += sum;
 sum = integral_img[i * width + x];
 }
 }
 
 kernel void weight_accum(global float *sum, global float *weight,
- global uint4 *integral_img, __read_only image2d_t src,
+ global float4 *integral_img, __read_only image2d_t 
src,
  int width, int height, int p, float h,
  int4 dx, int4 dy)
 {
@@ -75,16 +72,16 @@ kernel void weight_accum(global float *sum, global float 
*weight,
 int y = get_global_id(1);
 int4 xoff = x + dx;
 int4 yoff = y + dy;
-uint4 a = 0, b = 0, c = 0, d = 0;
-uint4 src_pix = 0;
+float4 a = 0, b = 0, c = 0, d = 0;
+float4 src_pix = 0;
 
 // out-of-bounding-box?
 int oobb = (x - p) < 0 || (y - p) < 0 || (y + p) >= height || (x + p) >= 
width;
 
-src_pix.x = (int)(255 * read_imagef(src, sampler, (int2)(xoff.x, 
yoff.x)).x);
-src_pix.y = (int)(255 * read_imagef(src, sampler, (int2)(xoff.y, 
yoff.y)).x);
-src_pix.z = (int)(255 * read_imagef(src, sampler, (int2)(xoff.z, 
yoff.z)).x);
-src_pix.w = (int)(255 * read_imagef(src, sampler, (int2)(xoff.w, 
yoff.w)).x);
+src_pix.x = read_imagef(src, sampler, (int2)(xoff.x, yoff.x)).x;
+src_pix.y = read_imagef(src, sampler, (int2)(xoff.y, yoff.y)).x;
+src_pix.z = read_imagef(src, sampler, (int2)(xoff.z, yoff.z)).x;
+src_pix.w = read_imagef(src, sampler, (int2)(xoff.w, yoff.w)).x;
 if (!oobb) {
 a = integral_img[(y - p) * width + x - p];
 b = integral_img[(y + p) * width + x - p];
@@ -93,7 +90,7 @@ kernel void weight_accum(global float *sum, global float 
*weight,
 }
 
 float4 patch_diff = convert_float4(d + a - c - b);
-float4 w = native_exp(-patch_diff / (h * h));
+float4 w = native_exp(-patch_diff * (float4)(255.0f * 255.0f) / (h * h));
 float w_sum = w.x + w.y + w.z + w.w;
 weight[y * width + x] += w_sum;
 sum[y * width + x] += dot(w, convert_float4

Re: [FFmpeg-devel] [PATCH 01/48] avcodec/packet: deprecate av_init_packet()

[James Almer]

On 3/21/2021 8:13 PM, Hendrik Leppkes wrote:

On Sun, Mar 21, 2021 at 3:24 PM James Almer  wrote:


How about adding the deprecation attribute to prompt people to read the
doxy, where we state the field is not going away, just changing types?
Otherwise i don't think people will notice.


I really don't like such solutions. You get warning spam in user code
with basically no way to remedy them.

- Hendrik


I'm going to add a new field in the end. A change of type can't ensure 
projects that don't migrate stop compiling (Like it happens when a field 
is removed), and instead will unexpectedly crash if they try to access 
it the wrong way.


But i can't do it until after the bump because libavdevice is locking 
every AVStream field offset.

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

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

[FFmpeg-devel] [PATCH 1/3] avcodec/kmvc: Prefer in-band palette

[Andreas Rheinhardt]

Fixes decoding of https://samples.ffmpeg.org/V-codecs/KMVC/LOGO2.AVI

Signed-off-by: Andreas Rheinhardt 
---
 libavcodec/kmvc.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/libavcodec/kmvc.c b/libavcodec/kmvc.c
index cd9e32f443..8d9f0a9693 100644
--- a/libavcodec/kmvc.c
+++ b/libavcodec/kmvc.c
@@ -275,6 +275,8 @@ static int decode_frame(AVCodecContext * avctx, void *data, 
int *got_frame,
 if ((ret = ff_get_buffer(avctx, frame, 0)) < 0)
 return ret;
 
+frame->palette_has_changed = ff_copy_palette(ctx->pal, avpkt, avctx);
+
 header = bytestream2_get_byte(&ctx->g);
 
 /* blocksize 127 is really palette change event */
@@ -303,9 +305,6 @@ static int decode_frame(AVCodecContext * avctx, void *data, 
int *got_frame,
 }
 }
 
-if (ff_copy_palette(ctx->pal, avpkt, avctx))
-frame->palette_has_changed = 1;
-
 if (ctx->setpal) {
 ctx->setpal = 0;
 frame->palette_has_changed = 1;
-- 
2.27.0

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

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

[FFmpeg-devel] [PATCH 2/3] avcodec/kmvc: Move commonly used variables to the front of the context

[Andreas Rheinhardt]

Reduces codesize because the offset in pointer+offset addressing
requires less bytes to encode. Reduces the size of .text from 8871B
to 8146B (GCC 10, -O3, x64).

Signed-off-by: Andreas Rheinhardt 
---
 libavcodec/kmvc.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/libavcodec/kmvc.c b/libavcodec/kmvc.c
index 8d9f0a9693..dd1ae05f2d 100644
--- a/libavcodec/kmvc.c
+++ b/libavcodec/kmvc.c
@@ -44,12 +44,12 @@
 typedef struct KmvcContext {
 AVCodecContext *avctx;
 
+GetByteContext g;
+uint8_t *cur, *prev;
 int setpal;
 int palsize;
 uint32_t pal[MAX_PALSIZE];
-uint8_t *cur, *prev;
 uint8_t frm0[320 * 200], frm1[320 * 200];
-GetByteContext g;
 } KmvcContext;
 
 typedef struct BitBuf {
-- 
2.27.0

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

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

[FFmpeg-devel] [PATCH 3/3] avcodec/kmvc: Avoid branch when swapping pointers

[Andreas Rheinhardt]

Signed-off-by: Andreas Rheinhardt 
---
 libavcodec/kmvc.c | 8 +---
 1 file changed, 1 insertion(+), 7 deletions(-)

diff --git a/libavcodec/kmvc.c b/libavcodec/kmvc.c
index dd1ae05f2d..56c1977254 100644
--- a/libavcodec/kmvc.c
+++ b/libavcodec/kmvc.c
@@ -345,13 +345,7 @@ static int decode_frame(AVCodecContext * avctx, void 
*data, int *got_frame,
 }
 
 /* flip buffers */
-if (ctx->cur == ctx->frm0) {
-ctx->cur = ctx->frm1;
-ctx->prev = ctx->frm0;
-} else {
-ctx->cur = ctx->frm0;
-ctx->prev = ctx->frm1;
-}
+FFSWAP(uint8_t *, ctx->cur, ctx->prev);
 
 *got_frame = 1;
 
-- 
2.27.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 4/4] avfilter/vf_v360: refactor (i)flat_range for fisheye

[Daniel Playfair Cal]

I've tried that filtergraph and a few other similar ones and I'm not sure
what you mean - what exactly is the regression?

I tried it on this image with an equirectangular projection:
https://wiki.panotools.org/images/0/01/Big_ben_equirectangular.jpg

The only difference I can see is that there are less unmapped areas in the
output with the patches, because the final mapping from the output
equirectangular image to the intermediate fisheye image no longer fails to
map some areas which are present in the fisheye image. I would describe
this as an improvement?

On Mon, Mar 22, 2021 at 3:30 AM Paul B Mahol  wrote:

> Sorry, but I cannot apply this set as is, It makes at least one serious
> regression.
>
> For example try this filtergraph:
>
>
> v360=input=e:output=fisheye:h_fov=180:v_fov=180,v360=input=fisheye:output=e:ih_fov=180:iv_fov=180
>
> On Sun, Mar 21, 2021 at 1:45 PM Daniel Playfair Cal <
> daniel.playfair@gmail.com> wrote:
>
>> This changes the iflat_range and flat_range values for the fisheye
>> projection to match their meaning for the flat/rectilinear projection.
>> That is, the range is between the two x or two y coordinates of the
>> outermost points above/below or left/right of the center, in the
>> flat/rectilinear projection.
>>
>> Signed-off-by: Daniel Playfair Cal 
>> ---
>>  libavfilter/vf_v360.c | 19 +--
>>  1 file changed, 9 insertions(+), 10 deletions(-)
>>
>> diff --git a/libavfilter/vf_v360.c b/libavfilter/vf_v360.c
>> index 68bb2f7b0f..3158451963 100644
>> --- a/libavfilter/vf_v360.c
>> +++ b/libavfilter/vf_v360.c
>> @@ -2807,9 +2807,8 @@ static int prepare_fisheye_out(AVFilterContext *ctx)
>>  {
>>  V360Context *s = ctx->priv;
>>
>> -s->flat_range[0] = s->h_fov / 180.f;
>> -s->flat_range[1] = s->v_fov / 180.f;
>> -
>> +s->flat_range[0] = 0.5f * s->h_fov * M_PI / 180.f;
>> +s->flat_range[1] = 0.5f * s->v_fov * M_PI / 180.f;
>>  return 0;
>>  }
>>
>> @@ -2827,8 +2826,8 @@ static int fisheye_to_xyz(const V360Context *s,
>>int i, int j, int width, int height,
>>float *vec)
>>  {
>> -const float uf = s->flat_range[0] * ((2.f * i) / width  - 1.f);
>> -const float vf = s->flat_range[1] * ((2.f * j + 1.f) / height - 1.f);
>> +const float uf = 2.f * s->flat_range[0] / M_PI * ((2.f * i) / width
>> - 1.f);
>> +const float vf = 2.f * s->flat_range[1] / M_PI * ((2.f * j + 1.f) /
>> height - 1.f);
>>
>>  const float phi   = atan2f(vf, uf);
>>  const float theta = M_PI_2 * (1.f - hypotf(uf, vf));
>> @@ -2858,8 +2857,8 @@ static int prepare_fisheye_in(AVFilterContext *ctx)
>>  {
>>  V360Context *s = ctx->priv;
>>
>> -s->iflat_range[0] = s->ih_fov / 180.f;
>> -s->iflat_range[1] = s->iv_fov / 180.f;
>> +s->iflat_range[0] = 0.5f * s->ih_fov * M_PI / 180.f;
>> +s->iflat_range[1] = 0.5f * s->iv_fov * M_PI / 180.f;
>>
>>  return 0;
>>  }
>> @@ -2882,10 +2881,10 @@ static int xyz_to_fisheye(const V360Context *s,
>>  {
>>  const float h   = hypotf(vec[0], vec[1]);
>>  const float lh  = h > 0.f ? h : 1.f;
>> -const float phi = atan2f(h, vec[2]) / M_PI;
>> +const float phi = atan2f(h, vec[2]);
>>
>> -float uf = vec[0] / lh * phi / s->iflat_range[0];
>> -float vf = vec[1] / lh * phi / s->iflat_range[1];
>> +float uf = 0.5f * vec[0] / lh * phi / s->iflat_range[0];
>> +float vf = 0.5f * vec[1] / lh * phi / s->iflat_range[1];
>>
>>  const int visible = -0.5f < uf && uf < 0.5f && -0.5f < vf && vf <
>> 0.5f;
>>  int ui, vi;
>> --
>> 2.31.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] [PATCH] libavcodec/qsvdec: reinit decoder according to decode() return value

[wenbin . chen]

From: "Chen,Wenbin" 

FFmpeg-qsv decoder reinit codec when width and height change, but there
are not only resolution change need to reinit codec. I change it to use
return value from DecodeFrameAsync() to decide whether decoder need to
be reinitialized.

Signed-off-by Wenbin Chen 
---
 libavcodec/qsvdec.c | 10 --
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/libavcodec/qsvdec.c b/libavcodec/qsvdec.c
index bca6e217fa..124f3e0a7a 100644
--- a/libavcodec/qsvdec.c
+++ b/libavcodec/qsvdec.c
@@ -438,6 +438,12 @@ static int qsv_decode(AVCodecContext *avctx, QSVContext *q,
 
 } while (ret == MFX_WRN_DEVICE_BUSY || ret == MFX_ERR_MORE_SURFACE);
 
+if (ret == MFX_ERR_INCOMPATIBLE_VIDEO_PARAM) {
+q->reinit_flag = 1;
+av_log(avctx, AV_LOG_VERBOSE, "Video parameter change\n");
+return 0;
+}
+
 if (ret != MFX_ERR_NONE &&
 ret != MFX_ERR_MORE_DATA &&
 ret != MFX_WRN_VIDEO_PARAM_CHANGED &&
@@ -591,9 +597,9 @@ int ff_qsv_process_data(AVCodecContext *avctx, QSVContext 
*q,
 
 ret = qsv_decode_header(avctx, q, pkt, pix_fmt, ¶m);
 
-if (ret >= 0 && (q->orig_pix_fmt != 
ff_qsv_map_fourcc(param.mfx.FrameInfo.FourCC) ||
+if (q->reinit_flag || (ret >= 0 && (q->orig_pix_fmt != 
ff_qsv_map_fourcc(param.mfx.FrameInfo.FourCC) ||
 avctx->coded_width  != param.mfx.FrameInfo.Width ||
-avctx->coded_height != param.mfx.FrameInfo.Height)) {
+avctx->coded_height != param.mfx.FrameInfo.Height))) {
 AVPacket zero_pkt = {0};
 
 if (q->buffered_count) {
-- 
2.25.1

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

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

[FFmpeg-devel] [PATCH] libavcodec/qsvdec: use the param from decodeHeader to configure surface

[wenbin . chen]

From: "Chen,Wenbin" 

MSDK recognizes both yuv420p10 and yuv420p9 as MFX_FOURCC_P010, but param
are different. When decode yuv420p9 video, ffmpeg-qsv will use
yuv420p10le to configure surface which is different with param from
DecoderHeader and this will lead to error. Now change it use
param from decoderHeader to configure surface.

Signed-off-by Wenbin Chen 
---
 libavcodec/qsvdec.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/libavcodec/qsvdec.c b/libavcodec/qsvdec.c
index 569ccd4fba..3ab48ea7a2 100644
--- a/libavcodec/qsvdec.c
+++ b/libavcodec/qsvdec.c
@@ -309,13 +309,13 @@ static int alloc_frame(AVCodecContext *avctx, QSVContext 
*q, QSVFrame *frame)
 if (frame->frame->format == AV_PIX_FMT_QSV) {
 frame->surface = *(mfxFrameSurface1*)frame->frame->data[3];
 } else {
-frame->surface.Info = q->frame_info;
-
 frame->surface.Data.PitchLow = frame->frame->linesize[0];
 frame->surface.Data.Y= frame->frame->data[0];
 frame->surface.Data.UV   = frame->frame->data[1];
 }
 
+frame->surface.Info = q->frame_info;
+
 if (q->frames_ctx.mids) {
 ret = ff_qsv_find_surface_idx(&q->frames_ctx, frame);
 if (ret < 0)
-- 
2.25.1

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

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

[FFmpeg-devel] [PATCH] avcodec/put_bits: Restore x64 ABI compatibility with releases <= 4.3

[Andreas Rheinhardt]

88d80cb97528d52dac3178cf5393d6095eca6200 changed the type of
PutBitContext.BitBuf to uint64_t; it used to be an uint32_t.
While said structure is not public, it is nevertheless used by
certain avpriv functions and therefore crosses library boundaries:
avpriv_align_put_bits and avpriv_copy_bits were used in other libraries
in release 4.3 (and at the time of 88d80cb9) and so this commit broke
ABI.

This commit mitigates the trouble caused by this by using an uint32_t
again, but only for the 4.4 release branch and not the master branch,
as doing so for master, would break the ABI of master again, although
it is very unlikely that anyone would be helped by this (there don't
seem to be any users that combine libavcodec built from master and
libavformat from an old release: otherwise we would have received bug
reports about said ABI break).

Signed-off-by: Andreas Rheinhardt 
---
Important: This is only intended for the 4.4 release branch.

 libavcodec/put_bits.h | 7 ---
 1 file changed, 7 deletions(-)

diff --git a/libavcodec/put_bits.h b/libavcodec/put_bits.h
index cd66a82a44..f07944a8fb 100644
--- a/libavcodec/put_bits.h
+++ b/libavcodec/put_bits.h
@@ -35,16 +35,9 @@
 
 #include "version.h"
 
-#if ARCH_X86_64
-// TODO: Benchmark and optionally enable on other 64-bit architectures.
-typedef uint64_t BitBuf;
-#define AV_WBBUF AV_WB64
-#define AV_WLBUF AV_WL64
-#else
 typedef uint32_t BitBuf;
 #define AV_WBBUF AV_WB32
 #define AV_WLBUF AV_WL32
-#endif
 
 static const int BUF_BITS = 8 * sizeof(BitBuf);
 
-- 
2.27.0

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

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

[FFmpeg-devel] [PATCH] libavcodec/qsvenc: add more ChromaFormat support for mjpeg-qsv

[wenbin . chen]

From: "Chen,Wenbin" 

ChromaForamt for mjpeg-qsv is always set to yuv420, and this will be
wrong when encode other pixel format (for example yuyv422). I change
this assignment to be adaptive to pix_fmt.

Signed-off-by: Wenbin Chen 
---
 libavcodec/qsvenc.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/libavcodec/qsvenc.c b/libavcodec/qsvenc.c
index 566a5c8552..a0fc206364 100644
--- a/libavcodec/qsvenc.c
+++ b/libavcodec/qsvenc.c
@@ -445,7 +445,8 @@ static int init_video_param_jpeg(AVCodecContext *avctx, 
QSVEncContext *q)
 q->param.mfx.FrameInfo.CropH  = avctx->height;
 q->param.mfx.FrameInfo.AspectRatioW   = avctx->sample_aspect_ratio.num;
 q->param.mfx.FrameInfo.AspectRatioH   = avctx->sample_aspect_ratio.den;
-q->param.mfx.FrameInfo.ChromaFormat   = MFX_CHROMAFORMAT_YUV420;
+q->param.mfx.FrameInfo.ChromaFormat   = MFX_CHROMAFORMAT_YUV420 +
+!desc->log2_chroma_w + 
!desc->log2_chroma_h;
 q->param.mfx.FrameInfo.BitDepthLuma   = desc->comp[0].depth;
 q->param.mfx.FrameInfo.BitDepthChroma = desc->comp[0].depth;
 q->param.mfx.FrameInfo.Shift  = desc->comp[0].depth > 8;
-- 
2.25.1

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

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

[FFmpeg-devel] [PATCH] libavfilter/qsvvpp: change the output frame's width and height

[wenbin . chen]

From: "Chen,Wenbin" 

qsvvpp align the width and height with 16, and that may lead to error.
For example, when we use qsvvpp to resize frame to 1080p, qsvvpp will
align frame to 1088 which is different from the height of
encoder (1080) and this will be treated as resolution change. Now I 
assign the out_link's w/h to output
frame to overwrite the w/h got from hw_frame_ctx.

Signed-off-by: Wenbin Chen 
---
 libavfilter/qsvvpp.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/libavfilter/qsvvpp.c b/libavfilter/qsvvpp.c
index f216b3f248..8658a70083 100644
--- a/libavfilter/qsvvpp.c
+++ b/libavfilter/qsvvpp.c
@@ -476,6 +476,9 @@ static QSVFrame *query_frame(QSVVPPContext *s, AVFilterLink 
*outlink)
 return NULL;
 }
 
+out_frame->frame->width  = outlink->w;
+out_frame->frame->height = outlink->h;
+
 out_frame->surface = (mfxFrameSurface1 *)out_frame->frame->data[3];
 } else {
 /* Get a frame with aligned dimensions.
-- 
2.25.1

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

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

Re: [FFmpeg-devel] [PATCH v4] avformat/libsrt: print streamid at client

[Raghavendra Rao Sidlagatta]

On Wednesday, January 20, 2021 09:48 GMT, "Raghavendra Rao Sidlagatta" 
 wrote:
  
On Tuesday, October 06, 2020 08:18 BST, raghavendra 
 wrote:
 Print the SRT streamid at the client.
Logged to info.

Signed-off-by: raghavendra 
---
libavformat/libsrt.c | 9 +
1 file changed, 9 insertions(+)

diff --git a/libavformat/libsrt.c b/libavformat/libsrt.c
index 4025b24976..eed48c11cf 100644
--- a/libavformat/libsrt.c
+++ b/libavformat/libsrt.c
@@ -359,6 +359,13 @@ static int libsrt_set_options_pre(URLContext *h, int fd)
return 0;
}

+static void libsrt_dump_streamid(URLContext *h, int fd)
+{
+ char streamid[512];
+ int optlen = sizeof(streamid);
+ if (!libsrt_getsockopt(h, fd, SRTO_STREAMID, "SRTO_STREAMID", streamid, 
&optlen))
+ av_log(h, AV_LOG_INFO, "srt_streamid : %s\n", streamid);
+}

static int libsrt_setup(URLContext *h, const char *uri, int flags)
{
@@ -442,6 +449,8 @@ static int libsrt_setup(URLContext *h, const char *uri, int 
flags)
goto fail1;
listen_fd = fd;
fd = ret;
+ // dump srt streamid at client
+ libsrt_dump_streamid(h, fd);
} else {
if (s->mode == SRT_MODE_RENDEZVOUS) {
ret = srt_bind(fd, cur_ai->ai_addr, cur_ai->ai_addrlen);
--
2.25.1

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

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

Hello There,

Could you please let me know the upstream status of this patch?

Best Regards,
Ragahvendra
 


Hello There,

Could you please let me know the upstream status of this patch?

Best Regards,
Ragahvendra
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [PATCH 4/4] avfilter/vf_v360: refactor (i)flat_range for fisheye

[Paul B Mahol]

On Mon, Mar 22, 2021 at 5:09 AM Daniel Playfair Cal <
daniel.playfair@gmail.com> wrote:

> I've tried that filtergraph and a few other similar ones and I'm not sure
> what you mean - what exactly is the regression?
>
> I tried it on this image with an equirectangular projection:
> https://wiki.panotools.org/images/0/01/Big_ben_equirectangular.jpg
>
> The only difference I can see is that there are less unmapped areas in the
> output with the patches, because the final mapping from the output
> equirectangular image to the intermediate fisheye image no longer fails to
> map some areas which are present in the fisheye image. I would describe
> this as an improvement?
>

I disagree, if I use 180 hfov and 180 vfov it should not have extra areas
but only half of previous input.


>
> On Mon, Mar 22, 2021 at 3:30 AM Paul B Mahol  wrote:
>
>> Sorry, but I cannot apply this set as is, It makes at least one serious
>> regression.
>>
>> For example try this filtergraph:
>>
>>
>> v360=input=e:output=fisheye:h_fov=180:v_fov=180,v360=input=fisheye:output=e:ih_fov=180:iv_fov=180
>>
>> On Sun, Mar 21, 2021 at 1:45 PM Daniel Playfair Cal <
>> daniel.playfair@gmail.com> wrote:
>>
>>> This changes the iflat_range and flat_range values for the fisheye
>>> projection to match their meaning for the flat/rectilinear projection.
>>> That is, the range is between the two x or two y coordinates of the
>>> outermost points above/below or left/right of the center, in the
>>> flat/rectilinear projection.
>>>
>>> Signed-off-by: Daniel Playfair Cal 
>>> ---
>>>  libavfilter/vf_v360.c | 19 +--
>>>  1 file changed, 9 insertions(+), 10 deletions(-)
>>>
>>> diff --git a/libavfilter/vf_v360.c b/libavfilter/vf_v360.c
>>> index 68bb2f7b0f..3158451963 100644
>>> --- a/libavfilter/vf_v360.c
>>> +++ b/libavfilter/vf_v360.c
>>> @@ -2807,9 +2807,8 @@ static int prepare_fisheye_out(AVFilterContext
>>> *ctx)
>>>  {
>>>  V360Context *s = ctx->priv;
>>>
>>> -s->flat_range[0] = s->h_fov / 180.f;
>>> -s->flat_range[1] = s->v_fov / 180.f;
>>> -
>>> +s->flat_range[0] = 0.5f * s->h_fov * M_PI / 180.f;
>>> +s->flat_range[1] = 0.5f * s->v_fov * M_PI / 180.f;
>>>  return 0;
>>>  }
>>>
>>> @@ -2827,8 +2826,8 @@ static int fisheye_to_xyz(const V360Context *s,
>>>int i, int j, int width, int height,
>>>float *vec)
>>>  {
>>> -const float uf = s->flat_range[0] * ((2.f * i) / width  - 1.f);
>>> -const float vf = s->flat_range[1] * ((2.f * j + 1.f) / height -
>>> 1.f);
>>> +const float uf = 2.f * s->flat_range[0] / M_PI * ((2.f * i) /
>>> width  - 1.f);
>>> +const float vf = 2.f * s->flat_range[1] / M_PI * ((2.f * j + 1.f) /
>>> height - 1.f);
>>>
>>>  const float phi   = atan2f(vf, uf);
>>>  const float theta = M_PI_2 * (1.f - hypotf(uf, vf));
>>> @@ -2858,8 +2857,8 @@ static int prepare_fisheye_in(AVFilterContext *ctx)
>>>  {
>>>  V360Context *s = ctx->priv;
>>>
>>> -s->iflat_range[0] = s->ih_fov / 180.f;
>>> -s->iflat_range[1] = s->iv_fov / 180.f;
>>> +s->iflat_range[0] = 0.5f * s->ih_fov * M_PI / 180.f;
>>> +s->iflat_range[1] = 0.5f * s->iv_fov * M_PI / 180.f;
>>>
>>>  return 0;
>>>  }
>>> @@ -2882,10 +2881,10 @@ static int xyz_to_fisheye(const V360Context *s,
>>>  {
>>>  const float h   = hypotf(vec[0], vec[1]);
>>>  const float lh  = h > 0.f ? h : 1.f;
>>> -const float phi = atan2f(h, vec[2]) / M_PI;
>>> +const float phi = atan2f(h, vec[2]);
>>>
>>> -float uf = vec[0] / lh * phi / s->iflat_range[0];
>>> -float vf = vec[1] / lh * phi / s->iflat_range[1];
>>> +float uf = 0.5f * vec[0] / lh * phi / s->iflat_range[0];
>>> +float vf = 0.5f * vec[1] / lh * phi / s->iflat_range[1];
>>>
>>>  const int visible = -0.5f < uf && uf < 0.5f && -0.5f < vf && vf <
>>> 0.5f;
>>>  int ui, vi;
>>> --
>>> 2.31.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".