Re: [FFmpeg-devel] [PATCH v3 1/3] avfilter/vf_bwdif: consider chroma subsampling when enforcing minimum dimensions

[Thomas Mundt]

Cosmin Stejerean via ffmpeg-devel  schrieb am Sa.,
2. Dez. 2023, 21:17:

> From: Cosmin Stejerean 
>
> Fixes #10688
>
> Signed-off-by: Cosmin Stejerean 
> ---
>  libavfilter/vf_bwdif.c | 9 +
>  1 file changed, 5 insertions(+), 4 deletions(-)
>
> diff --git a/libavfilter/vf_bwdif.c b/libavfilter/vf_bwdif.c
> index 137cd5ef13..353cd0b61a 100644
> --- a/libavfilter/vf_bwdif.c
> +++ b/libavfilter/vf_bwdif.c
> @@ -191,13 +191,14 @@ static int config_props(AVFilterLink *link)
>  return ret;
>  }
>
> -if (link->w < 3 || link->h < 4) {
> -av_log(ctx, AV_LOG_ERROR, "Video of less than 3 columns or 4
> lines is not supported\n");
> +yadif->csp = av_pix_fmt_desc_get(link->format);
> +yadif->filter = filter;
> +
> +if (AV_CEIL_RSHIFT(link->w, yadif->csp->log2_chroma_w) < 3 ||
> AV_CEIL_RSHIFT(link->h, yadif->csp->log2_chroma_h) < 4) {
> +av_log(ctx, AV_LOG_ERROR, "Video with planes less than 3 columns
> or 4 lines is not supported\n");
>  return AVERROR(EINVAL);
>  }
>
> -yadif->csp = av_pix_fmt_desc_get(link->format);
> -yadif->filter = filter;
>  ff_bwdif_init_filter_line(>dsp, yadif->csp->comp[0].depth);
>
>  return 0;
> --
> 2.42.1
>

LGTM, thanks.

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

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

Re: [FFmpeg-devel] [PATCH v2 1/3] avfilter/vf_bwdif: consider chroma subsampling when enforcing minimum dimensions

[Thomas Mundt]

Am Do., 30. Nov. 2023 um 01:23 Uhr schrieb Cosmin Stejerean via
ffmpeg-devel :

> From: Cosmin Stejerean 
>
> Fixes #10688
>
> Signed-off-by: Cosmin Stejerean 
> ---
>  libavfilter/vf_bwdif.c | 13 ++---
>  1 file changed, 10 insertions(+), 3 deletions(-)
>
> diff --git a/libavfilter/vf_bwdif.c b/libavfilter/vf_bwdif.c
> index 137cd5ef13..80aa85a48b 100644
> --- a/libavfilter/vf_bwdif.c
> +++ b/libavfilter/vf_bwdif.c
> @@ -191,12 +191,19 @@ static int config_props(AVFilterLink *link)
>  return ret;
>  }
>
> -if (link->w < 3 || link->h < 4) {
> -av_log(ctx, AV_LOG_ERROR, "Video of less than 3 columns or 4
> lines is not supported\n");
> +const AVPixFmtDescriptor *desc = av_pix_fmt_desc_get(link->format);
> +
> +int h = link->h;
> +int w = link->w;
> +int h_chroma = AV_CEIL_RSHIFT(h, desc->log2_chroma_h);
> +int w_chroma = AV_CEIL_RSHIFT(w, desc->log2_chroma_w);
> +
> +if (w < 3 || w_chroma < 3 || h < 4 || h_chroma < 4) {
> +av_log(ctx, AV_LOG_ERROR, "Video with planes less than 3 columns
> or 4 lines is not supported\n");
>  return AVERROR(EINVAL);
>  }
>
> -yadif->csp = av_pix_fmt_desc_get(link->format);
> +yadif->csp = desc;
>  yadif->filter = filter;
>  ff_bwdif_init_filter_line(>dsp, yadif->csp->comp[0].depth);
>
> I think mixed declarations are not allowed.
Also log2_chroma_w/h should never be negative, so why not just do:

if (AV_CEIL_RSHIFT(link->w,  yadif->csp->log2_chroma_w) < 3 ||
AV_CEIL_RSHIFT(link->h,  yadif->csp->log2_chroma_h) < 4)

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

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

Re: [FFmpeg-devel] [PATCH] avfilter/vf_bwdif: consider chroma subsampling when enforcing minimum dimensions

[Thomas Mundt]

Hi Cosmin,

Cosmin Stejerean via ffmpeg-devel  schrieb am Sa.,
25. Nov. 2023, 21:39:

> Fixes #10688
>
> Signed-off-by: Cosmin Stejerean 
> ---
>  libavfilter/vf_bwdif.c | 12 
>  1 file changed, 12 insertions(+)
>
> diff --git a/libavfilter/vf_bwdif.c b/libavfilter/vf_bwdif.c
> index 137cd5ef13..bce11c39f7 100644
> --- a/libavfilter/vf_bwdif.c
> +++ b/libavfilter/vf_bwdif.c
> @@ -197,6 +197,18 @@ static int config_props(AVFilterLink *link)
>  }
>
>  yadif->csp = av_pix_fmt_desc_get(link->format);
> +
> +if (yadif->csp->nb_components > 1) {
> +int w_chroma, h_chroma;
> +h_chroma = AV_CEIL_RSHIFT(link->h, yadif->csp->log2_chroma_h);
> +w_chroma = AV_CEIL_RSHIFT(link->w, yadif->csp->log2_chroma_w);
> +
> +if (w_chroma < 3 || h_chroma < 4) {
> +av_log(ctx, AV_LOG_ERROR, "Video with planes less than 3
> columns or 4 lines is not supported\n");
> +return AVERROR(EINVAL);
> +}
> +}
> +
>

Thanks for your quick patch.
Could you please make the size check for all components and remove the old
one to avoid having two size checks in a row?

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

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

Re: [FFmpeg-devel] [PATCH] lavfi/bwdif: remove interpolated sample clipping

[Thomas Mundt]

Lynne  schrieb am Di., 4. Juli 2023, 00:54:

> Jul 4, 2023, 00:08 by tmund...@gmail.com:
>
> > Am So., 2. Juli 2023 um 20:58 Uhr schrieb Lynne :
> >
> >> Jul 2, 2023, 20:41 by tmund...@gmail.com:
> >>
> >> > Am So., 2. Juli 2023 um 18:57 Uhr schrieb Lynne :
> >> >
> >> >> Jul 2, 2023, 18:54 by d...@lynne.ee:
> >> >>
> >> >> > The issue is that clipping the interpolated temporal sample against
> >> >> > the spatially predicted sample causes artifacts to appear.
> >> >> >
> >> >> > Discovered while writing the Vulkan version (where I omitted the
> >> >> > same check).
> >> >> >
> >> >> > The clipping in the code is carried over from yadif. Removing the
> >> >> > same code in yadif does not make any difference to the output.
> >> >> > I think that the check was simply ill-adapted to the new prediction
> >> >> > code and does more harm.
> >> >> >
> >> >> > I tested replacing the range clip with only an FFMAX, and only an
> >> >> > FFMIN, but in both cases, artifacts still appeared.
> >> >> >
> >> >> > Test sample 1:
> >> >> https://files.lynne.ee/testsamples/mbaff_1080i60_idx.mkvTest sample
> 2:
> >> >> https://files.lynne.ee/testsamples/mbaff_bdmv_1080i60_8slice.mkv
> >> >> >
> >> >> > Command line:
> >> >> > ./ffmpeg_g -cpuflags 0 -i  -vf bwdif=mode=send_field -c:v
> >> >> rawvideo -y .nut
> >> >> > Make sure to disable the assembly.
> >> >> >
> >> >> > Comparisons:
> >> >> > https://files.lynne.ee/bwdif_01_before.png
> >> >> > https://files.lynne.ee/bwdif_01_after.png
> >> >> > Generated from sample 1 via:
> >> >> > ffmpeg -ss 00:00:00.184 -i .nut -vf
> >> >> crop=w=420:h=240:x=700:y=300,scale=iw*2:ih*2 -y .png
> >> >> >
> >> >> > https://files.lynne.ee/bwdif_02_before.png
> >> >> > https://files.lynne.ee/bwdif_02_after.pngffmpeg -ss 00:00:00.417
> -i
> >> >> .nut -vf crop=w=420:h=240:x=1100:y=200,scale=iw*2:ih*2 -y
> >> >> .png
> >> >> >
> >> >>
> >> >> Corrected links for the second sample:
> >> >>
> >> >> https://files.lynne.ee/bwdif_02_before.png
> >> >> https://files.lynne.ee/bwdif_02_after.png
> >> >> ffmpeg -ss 00:00:00.417 -i .nut -vf
> >> >> crop=w=420:h=240:x=1100:y=200,scale=iw*2:ih*2 -y .png
> >> >>
> >> >> I'm sure I hit a newline. The artifacts are a lot more noticeable in
> the
> >> >> second sample.
> >> >>
> >> >
> >> > I developed the bwdif to achieve the best possible balance between
> speed
> >> > and quality of all different image contents from the broadcast point
> of
> >> > view. This includes moving video as well as moving and static graphic
> >> > elements. Unfortunately, the improvement of one image content often
> leads
> >> > to the degradation of another. The code you removed fundamentally
> >> > stabilizes the static graphic elements. This outweighs the slightly
> more
> >> > frequent artifacts in moving video considering the general purpose of
> the
> >> > filter.
> >> >
> >>
> >> Could you post examples? I've been unable to find any that look worse
> >> with the patch.
> >>
> >
> > Unfortunately, I no longer have most of the test material that I used
> years
> > ago at the development of the bwdif.
> > But on the quick I have this clip with an "Archiv" insert. With your
> patch
> > the letters are jumping. Without your patch they stay static.
> > https://www.dropbox.com/s/jzoezjbi3ho9nja/bwdif-test.mov?dl=1
> > ffmpeg.exe -cpuflags 0 -i "bwdif-test.mov" -vf "bwdif=1:-1:1,
> > scale=1920:1080" -sws_flags lanczos -aspect 16:9 -c:v libx264 -crf 21
> > "bwdif_original.mp4"
> > ffmpeg_lynne_patch.exe -cpuflags 0 -i "bwdif-test.mov" -vf "bwdif=1:-1:1,
> > scale=1920:1080" -sws_flags lanczos -aspect 16:9 -c:v libx264 -crf 21
> > "bwdif_lynne_patch.mp4"
> > https://www.dropbox.com/s/tonsomtkhyaha91/bwdif_original.mp4?dl=1
> > https://www.dropbox.com/s/aaj8o5yzlocu55z/bwdif_lynne_patch.mp4?dl=1
> >
>
> Can confirm the letters are jumping with my patch.
> Fair enough, consider this patch dropped. I've added the check
> in Vulkan to make that version exact to C.
> Thanks for testing and writing the filter!
>

Thanks

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

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

Re: [FFmpeg-devel] [PATCH v2 12/15] avfilter/vf_bwdif: Add a filter_line3 method for optimisation

[Thomas Mundt]

Am Mo., 3. Juli 2023 um 10:27 Uhr schrieb John Cox :

> On Mon, 3 Jul 2023 00:12:46 +0300 (EEST), you wrote:
>
> >On Sun, 2 Jul 2023, Thomas Mundt wrote:
> >
> >> Am So., 2. Juli 2023 um 14:34 Uhr schrieb John Cox :
> >>   Add an optional filter_line3 to the available optimisations.
> >>
> >>   filter_line3 is equivalent to filter_line, memcpy, filter_line
> >>
> >>   filter_line shares quite a number of loads and some calculations
> >>   in
> >>   common with its next iteration and testing shows that using
> >>   aarch64
> >>   neon filter_line3s performance is 30% better than two
> >>   filter_lines
> >>   and a memcpy.
> >>
> >>   Signed-off-by: John Cox 
> >>   ---
> >>libavfilter/bwdif.h|  7 +++
> >>libavfilter/vf_bwdif.c | 31 +++
> >>2 files changed, 38 insertions(+)
> >>
> >>   diff --git a/libavfilter/bwdif.h b/libavfilter/bwdif.h
> >>   index cce99953f3..496cec72ef 100644
> >>   --- a/libavfilter/bwdif.h
> >>   +++ b/libavfilter/bwdif.h
> >>   @@ -35,6 +35,9 @@ typedef struct BWDIFContext {
> >>void (*filter_edge)(void *dst, void *prev, void *cur, void
> >>   *next,
> >>int w, int prefs, int mrefs, int
> >>   prefs2, int mrefs2,
> >>int parity, int clip_max, int spat);
> >>   +void (*filter_line3)(void *dst, int dstride,
> >>   + const void *prev, const void *cur,
> >>   const void *next, int prefs,
> >>   + int w, int parity, int clip_max);
> >>} BWDIFContext;
> >>
> >>void ff_bwdif_init_filter_line(BWDIFContext *bwdif, int
> >>   bit_depth);
> >>   @@ -53,4 +56,8 @@ void ff_bwdif_filter_line_c(void *dst1, void
> >>   *prev1, void *cur1, void *next1,
> >>int prefs3, int mrefs3, int prefs4,
> >>   int mrefs4,
> >>int parity, int clip_max);
> >>
> >>   +void ff_bwdif_filter_line3_c(void * dst1, int d_stride,
> >>   + const void * prev1, const void *
> >>   cur1, const void * next1, int s_stride,
> >>   + int w, int parity, int clip_max);
> >>   +
> >>#endif /* AVFILTER_BWDIF_H */
> >>   diff --git a/libavfilter/vf_bwdif.c b/libavfilter/vf_bwdif.c
> >>   index 26349da1fd..52bc676cf8 100644
> >>   --- a/libavfilter/vf_bwdif.c
> >>   +++ b/libavfilter/vf_bwdif.c
> >>   @@ -150,6 +150,31 @@ void ff_bwdif_filter_line_c(void *dst1,
> >>   void *prev1, void *cur1, void *next1,
> >>FILTER2()
> >>}
> >>
> >>   +#define NEXT_LINE()\
> >>   +dst += d_stride; \
> >>   +prev += prefs; \
> >>   +cur  += prefs; \
> >>   +next += prefs;
> >>   +
> >>   +void ff_bwdif_filter_line3_c(void * dst1, int d_stride,
> >>   + const void * prev1, const void *
> >>   cur1, const void * next1, int s_stride,
> >>   + int w, int parity, int clip_max)
> >>   +{
> >>   +const int prefs = s_stride;
> >>   +uint8_t * dst  = dst1;
> >>   +const uint8_t * prev = prev1;
> >>   +const uint8_t * cur  = cur1;
> >>   +const uint8_t * next = next1;
> >>   +
> >>   +ff_bwdif_filter_line_c(dst, (void*)prev, (void*)cur,
> >>   (void*)next, w,
> >>   +   prefs, -prefs, prefs * 2, - prefs *
> >>   2, prefs * 3, -prefs * 3, prefs * 4, -prefs * 4, parity,
> >>   clip_max);
> >>   +NEXT_LINE();
> >>   +memcpy(dst, cur, w);
> >>   +NEXT_LINE();
> >>   +ff_bwdif_filter_line_c(dst, (void*)prev, (void*)cur,
> >>   (void*)next, w,
> >>   +   prefs, -prefs, prefs * 2, - prefs *
> >>   2, prefs * 3, -prefs * 3, prefs * 4, -prefs * 4, parity,
> >>   clip_max);
> >>   +}
> >>   +
> >>void ff_bwdif_filter_edge_c(void *dst1, void *prev1, voi

Re: [FFmpeg-devel] [PATCH] lavfi/bwdif: remove interpolated sample clipping

[Thomas Mundt]

Am So., 2. Juli 2023 um 20:58 Uhr schrieb Lynne :

> Jul 2, 2023, 20:41 by tmund...@gmail.com:
>
> > Am So., 2. Juli 2023 um 18:57 Uhr schrieb Lynne :
> >
> >> Jul 2, 2023, 18:54 by d...@lynne.ee:
> >>
> >> > The issue is that clipping the interpolated temporal sample against
> >> > the spatially predicted sample causes artifacts to appear.
> >> >
> >> > Discovered while writing the Vulkan version (where I omitted the
> >> > same check).
> >> >
> >> > The clipping in the code is carried over from yadif. Removing the
> >> > same code in yadif does not make any difference to the output.
> >> > I think that the check was simply ill-adapted to the new prediction
> >> > code and does more harm.
> >> >
> >> > I tested replacing the range clip with only an FFMAX, and only an
> >> > FFMIN, but in both cases, artifacts still appeared.
> >> >
> >> > Test sample 1:
> >> https://files.lynne.ee/testsamples/mbaff_1080i60_idx.mkvTest sample 2:
> >> https://files.lynne.ee/testsamples/mbaff_bdmv_1080i60_8slice.mkv
> >> >
> >> > Command line:
> >> > ./ffmpeg_g -cpuflags 0 -i  -vf bwdif=mode=send_field -c:v
> >> rawvideo -y .nut
> >> > Make sure to disable the assembly.
> >> >
> >> > Comparisons:
> >> > https://files.lynne.ee/bwdif_01_before.png
> >> > https://files.lynne.ee/bwdif_01_after.png
> >> > Generated from sample 1 via:
> >> > ffmpeg -ss 00:00:00.184 -i .nut -vf
> >> crop=w=420:h=240:x=700:y=300,scale=iw*2:ih*2 -y .png
> >> >
> >> > https://files.lynne.ee/bwdif_02_before.png
> >> > https://files.lynne.ee/bwdif_02_after.pngffmpeg -ss 00:00:00.417 -i
> >> .nut -vf crop=w=420:h=240:x=1100:y=200,scale=iw*2:ih*2 -y
> >> .png
> >> >
> >>
> >> Corrected links for the second sample:
> >>
> >> https://files.lynne.ee/bwdif_02_before.png
> >> https://files.lynne.ee/bwdif_02_after.png
> >> ffmpeg -ss 00:00:00.417 -i .nut -vf
> >> crop=w=420:h=240:x=1100:y=200,scale=iw*2:ih*2 -y .png
> >>
> >> I'm sure I hit a newline. The artifacts are a lot more noticeable in the
> >> second sample.
> >>
> >
> > I developed the bwdif to achieve the best possible balance between speed
> > and quality of all different image contents from the broadcast point of
> > view. This includes moving video as well as moving and static graphic
> > elements. Unfortunately, the improvement of one image content often leads
> > to the degradation of another. The code you removed fundamentally
> > stabilizes the static graphic elements. This outweighs the slightly more
> > frequent artifacts in moving video considering the general purpose of the
> > filter.
> >
>
> Could you post examples? I've been unable to find any that look worse
> with the patch.
>

Unfortunately, I no longer have most of the test material that I used years
ago at the development of the bwdif.
But on the quick I have this clip with an "Archiv" insert. With your patch
the letters are jumping. Without your patch they stay static.
https://www.dropbox.com/s/jzoezjbi3ho9nja/bwdif-test.mov?dl=1
ffmpeg.exe -cpuflags 0 -i "bwdif-test.mov" -vf "bwdif=1:-1:1,
scale=1920:1080" -sws_flags lanczos -aspect 16:9 -c:v libx264 -crf 21
"bwdif_original.mp4"
ffmpeg_lynne_patch.exe -cpuflags 0 -i "bwdif-test.mov" -vf "bwdif=1:-1:1,
scale=1920:1080" -sws_flags lanczos -aspect 16:9 -c:v libx264 -crf 21
"bwdif_lynne_patch.mp4"
https://www.dropbox.com/s/tonsomtkhyaha91/bwdif_original.mp4?dl=1
https://www.dropbox.com/s/aaj8o5yzlocu55z/bwdif_lynne_patch.mp4?dl=1

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

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

Re: [FFmpeg-devel] [PATCH] lavfi/bwdif: remove interpolated sample clipping

[Thomas Mundt]

Am So., 2. Juli 2023 um 18:57 Uhr schrieb Lynne :

> Jul 2, 2023, 18:54 by d...@lynne.ee:
>
> > The issue is that clipping the interpolated temporal sample against
> > the spatially predicted sample causes artifacts to appear.
> >
> > Discovered while writing the Vulkan version (where I omitted the
> > same check).
> >
> > The clipping in the code is carried over from yadif. Removing the
> > same code in yadif does not make any difference to the output.
> > I think that the check was simply ill-adapted to the new prediction
> > code and does more harm.
> >
> > I tested replacing the range clip with only an FFMAX, and only an
> > FFMIN, but in both cases, artifacts still appeared.
> >
> > Test sample 1:
> https://files.lynne.ee/testsamples/mbaff_1080i60_idx.mkvTest sample 2:
> https://files.lynne.ee/testsamples/mbaff_bdmv_1080i60_8slice.mkv
> >
> > Command line:
> > ./ffmpeg_g -cpuflags 0 -i  -vf bwdif=mode=send_field -c:v
> rawvideo -y .nut
> > Make sure to disable the assembly.
> >
> > Comparisons:
> > https://files.lynne.ee/bwdif_01_before.png
> > https://files.lynne.ee/bwdif_01_after.png
> > Generated from sample 1 via:
> > ffmpeg -ss 00:00:00.184 -i .nut -vf
> crop=w=420:h=240:x=700:y=300,scale=iw*2:ih*2 -y .png
> >
> > https://files.lynne.ee/bwdif_02_before.png
> > https://files.lynne.ee/bwdif_02_after.pngffmpeg -ss 00:00:00.417 -i
> .nut -vf crop=w=420:h=240:x=1100:y=200,scale=iw*2:ih*2 -y
> .png
> >
>
> Corrected links for the second sample:
>
> https://files.lynne.ee/bwdif_02_before.png
> https://files.lynne.ee/bwdif_02_after.png
> ffmpeg -ss 00:00:00.417 -i .nut -vf
> crop=w=420:h=240:x=1100:y=200,scale=iw*2:ih*2 -y .png
>
> I'm sure I hit a newline. The artifacts are a lot more noticeable in the
> second sample.
>

I developed the bwdif to achieve the best possible balance between speed
and quality of all different image contents from the broadcast point of
view. This includes moving video as well as moving and static graphic
elements. Unfortunately, the improvement of one image content often leads
to the degradation of another. The code you removed fundamentally
stabilizes the static graphic elements. This outweighs the slightly more
frequent artifacts in moving video considering the general purpose of the
filter.
For noisy pure motion video content, for example, the w3fdif is better
suited, since it does not make if/else decisions and thus does not produce
artifacts.

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

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

Re: [FFmpeg-devel] [PATCH v2 12/15] avfilter/vf_bwdif: Add a filter_line3 method for optimisation

[Thomas Mundt]

Am So., 2. Juli 2023 um 14:34 Uhr schrieb John Cox :

> Add an optional filter_line3 to the available optimisations.
>
> filter_line3 is equivalent to filter_line, memcpy, filter_line
>
> filter_line shares quite a number of loads and some calculations in
> common with its next iteration and testing shows that using aarch64
> neon filter_line3s performance is 30% better than two filter_lines
> and a memcpy.
>
> Signed-off-by: John Cox 
> ---
>  libavfilter/bwdif.h|  7 +++
>  libavfilter/vf_bwdif.c | 31 +++
>  2 files changed, 38 insertions(+)
>
> diff --git a/libavfilter/bwdif.h b/libavfilter/bwdif.h
> index cce99953f3..496cec72ef 100644
> --- a/libavfilter/bwdif.h
> +++ b/libavfilter/bwdif.h
> @@ -35,6 +35,9 @@ typedef struct BWDIFContext {
>  void (*filter_edge)(void *dst, void *prev, void *cur, void *next,
>  int w, int prefs, int mrefs, int prefs2, int
> mrefs2,
>  int parity, int clip_max, int spat);
> +void (*filter_line3)(void *dst, int dstride,
> + const void *prev, const void *cur, const void
> *next, int prefs,
> + int w, int parity, int clip_max);
>  } BWDIFContext;
>
>  void ff_bwdif_init_filter_line(BWDIFContext *bwdif, int bit_depth);
> @@ -53,4 +56,8 @@ void ff_bwdif_filter_line_c(void *dst1, void *prev1,
> void *cur1, void *next1,
>  int prefs3, int mrefs3, int prefs4, int
> mrefs4,
>  int parity, int clip_max);
>
> +void ff_bwdif_filter_line3_c(void * dst1, int d_stride,
> + const void * prev1, const void * cur1, const
> void * next1, int s_stride,
> + int w, int parity, int clip_max);
> +
>  #endif /* AVFILTER_BWDIF_H */
> diff --git a/libavfilter/vf_bwdif.c b/libavfilter/vf_bwdif.c
> index 26349da1fd..52bc676cf8 100644
> --- a/libavfilter/vf_bwdif.c
> +++ b/libavfilter/vf_bwdif.c
> @@ -150,6 +150,31 @@ void ff_bwdif_filter_line_c(void *dst1, void *prev1,
> void *cur1, void *next1,
>  FILTER2()
>  }
>
> +#define NEXT_LINE()\
> +dst += d_stride; \
> +prev += prefs; \
> +cur  += prefs; \
> +next += prefs;
> +
> +void ff_bwdif_filter_line3_c(void * dst1, int d_stride,
> + const void * prev1, const void * cur1, const
> void * next1, int s_stride,
> + int w, int parity, int clip_max)
> +{
> +const int prefs = s_stride;
> +uint8_t * dst  = dst1;
> +const uint8_t * prev = prev1;
> +const uint8_t * cur  = cur1;
> +const uint8_t * next = next1;
> +
> +ff_bwdif_filter_line_c(dst, (void*)prev, (void*)cur, (void*)next, w,
> +   prefs, -prefs, prefs * 2, - prefs * 2, prefs *
> 3, -prefs * 3, prefs * 4, -prefs * 4, parity, clip_max);
> +NEXT_LINE();
> +memcpy(dst, cur, w);
> +NEXT_LINE();
> +ff_bwdif_filter_line_c(dst, (void*)prev, (void*)cur, (void*)next, w,
> +   prefs, -prefs, prefs * 2, - prefs * 2, prefs *
> 3, -prefs * 3, prefs * 4, -prefs * 4, parity, clip_max);
> +}
> +
>  void ff_bwdif_filter_edge_c(void *dst1, void *prev1, void *cur1, void
> *next1,
>  int w, int prefs, int mrefs, int prefs2, int
> mrefs2,
>  int parity, int clip_max, int spat)
> @@ -244,6 +269,11 @@ static int filter_slice(AVFilterContext *ctx, void
> *arg, int jobnr, int nb_jobs)
> refs << 1, -(refs << 1),
> td->parity ^ td->tff, clip_max,
> (y < 2) || ((y + 3) > td->h) ? 0 : 1);
> +} else if (s->filter_line3 && y + 2 < slice_end && y + 6 <
> td->h) {
> +s->filter_line3(dst, td->frame->linesize[td->plane],
> +prev, cur, next, linesize, td->w,
> +td->parity ^ td->tff, clip_max);
> +y += 2;
>  } else {
>  s->filter_line(dst, prev, cur, next, td->w,
> refs, -refs, refs << 1, -(refs << 1),
>

Maybe I'm missing something, but doesn't this kick out most of the x86 SIMD
optimization because there is no filter_line3?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [PATCH] avfilter/vf_bwdif: Remove undesireable spatial preference logic

[Thomas Mundt]

Lynne  schrieb am So., 11. Juni 2023, 20:11:

> Jun 11, 2023, 04:53 by phil...@overt.org:
>
> > On Sat, 25 Mar 2023 00:02:03 +0100
> > Thomas Mundt  wrote:
> >
> >> Hi Philip,
> >>
> >> Philip Langdale  schrieb am Fr., 24. März 2023,
> >> 23:21:
> >>
> >> > bwdif inherited this check from yadif, which was originally
> >> > supposed to prefer the spatial predictor if the temporal predictor
> >> > was too far off.
> >> >
> >> > However, the core bwdif algorithm already accounts for the spatial
> >> > predictor, so this additional check actually ends up preferring a
> >> > worse value, reducing the overall quality.
> >> >
> >> > This was found by cyanreg while writing bwdif_vulkan, and the visual
> >> > improvement is pretty dramatic in some samples. If we agree that
> >> > this change is desirable, we should update all implementations.
> >> >
> >> > Signed-off-by: Philip Langdale 
> >> > ---
> >> >  libavfilter/vf_bwdif.c | 5 -
> >> >  1 file changed, 5 deletions(-)
> >> >
> >> > diff --git a/libavfilter/vf_bwdif.c b/libavfilter/vf_bwdif.c
> >> > index 65c617ebb3..441bb11e7b 100644
> >> > --- a/libavfilter/vf_bwdif.c
> >> > +++ b/libavfilter/vf_bwdif.c
> >> > @@ -106,11 +106,6 @@ typedef struct ThreadData {
> >> >  interpol = (c + e) >> 1;
> >> >
> >> >  #define FILTER2() \
> >> > -if (interpol > d + diff) \
> >> > -interpol = d + diff; \
> >> > -else if (interpol < d - diff) \
> >> > -interpol = d - diff; \
> >> > - \
> >> >
> >>
> >> Removing this will make lower thirds and other graphic jump up and
> >> down each frame. It is the main improvement over w3fdif that I have
> >> ported from yadif.
> >> Can you provide samples including still graphics that are improved
> >> with this patch?
> >>
> >
> > Hi Thomas,
> >
> > Sorry for this thread going unanswered for so long. With the Vulkan
> > hwaccel stuff sorted out, I wanted to come back to this. I discussed
> > more with Lynne and we're no longer convinced this change is obviously
> > desirable. You are right about the jumping behaviour - and although
> > there are samples (eg: the burosch ones on samples.ffmpeg.org) which
> > look better with the change, I don't think that's something to over
> > index on.
> >
>
> I don't recall agreeing that this is desirable.
> bwdif_vulkan still looks better than bwdif or bwdif_cuda (and it's got
> proper edge handling).
>

Could you please prove this claim with some samples? I don't have any
suitable hardware for Vulkan.
Just saw that bwdif_vulkan was added to master. Somehow I didn't see the
commit in the cvs log.

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

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

Re: [FFmpeg-devel] [PATCH 2/3] checkasm: add test for bwdif

[Thomas Mundt]

Hi James,

Am Mo., 20. Feb. 2023 um 20:59 Uhr schrieb James Darnley :

> ---
>  tests/checkasm/Makefile   |  1 +
>  tests/checkasm/checkasm.c |  3 ++
>  tests/checkasm/checkasm.h |  1 +
>  tests/checkasm/vf_bwdif.c | 70 +++
>  tests/fate/checkasm.mak   |  1 +
>  5 files changed, 76 insertions(+)
>  create mode 100644 tests/checkasm/vf_bwdif.c
>
> diff --git a/tests/checkasm/Makefile b/tests/checkasm/Makefile
> index a6f06c7007..b6a43f181f 100644
> --- a/tests/checkasm/Makefile
> +++ b/tests/checkasm/Makefile
> @@ -40,6 +40,7 @@ CHECKASMOBJS-$(CONFIG_AVCODEC)  +=
> $(AVCODECOBJS-yes)
>  # libavfilter tests
>  AVFILTEROBJS-$(CONFIG_AFIR_FILTER) += af_afir.o
>  AVFILTEROBJS-$(CONFIG_BLEND_FILTER) += vf_blend.o
> +AVFILTEROBJS-$(CONFIG_BWDIF_FILTER)  += vf_bwdif.o
>  AVFILTEROBJS-$(CONFIG_COLORSPACE_FILTER) += vf_colorspace.o
>  AVFILTEROBJS-$(CONFIG_EQ_FILTER) += vf_eq.o
>  AVFILTEROBJS-$(CONFIG_GBLUR_FILTER)  += vf_gblur.o
> diff --git a/tests/checkasm/checkasm.c b/tests/checkasm/checkasm.c
> index e96d84a7da..5e729cf0e0 100644
> --- a/tests/checkasm/checkasm.c
> +++ b/tests/checkasm/checkasm.c
> @@ -179,6 +179,9 @@ static const struct {
>  #if CONFIG_BLEND_FILTER
>  { "vf_blend", checkasm_check_blend },
>  #endif
> +#if CONFIG_BWDIF_FILTER
> +{ "vf_bwdif", checkasm_check_vf_bwdif },
> +#endif
>  #if CONFIG_COLORSPACE_FILTER
>  { "vf_colorspace", checkasm_check_colorspace },
>  #endif
> diff --git a/tests/checkasm/checkasm.h b/tests/checkasm/checkasm.h
> index 8744a81218..e9e73c6fa0 100644
> --- a/tests/checkasm/checkasm.h
> +++ b/tests/checkasm/checkasm.h
> @@ -82,6 +82,7 @@ void checkasm_check_utvideodsp(void);
>  void checkasm_check_v210dec(void);
>  void checkasm_check_v210enc(void);
>  void checkasm_check_vc1dsp(void);
> +void checkasm_check_vf_bwdif(void);
>  void checkasm_check_vf_eq(void);
>  void checkasm_check_vf_gblur(void);
>  void checkasm_check_vf_hflip(void);
> diff --git a/tests/checkasm/vf_bwdif.c b/tests/checkasm/vf_bwdif.c
> new file mode 100644
> index 00..e27f9b7494
> --- /dev/null
> +++ b/tests/checkasm/vf_bwdif.c
> @@ -0,0 +1,70 @@
> +/*
> + * This file is part of FFmpeg.
> + *
> + * FFmpeg is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + * FFmpeg is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License along
> + * with FFmpeg; if not, write to the Free Software Foundation, Inc.,
> + * 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
> + */
> +
> +#include 
> +#include "checkasm.h"
> +#include "libavcodec/internal.h"
> +#include "libavfilter/bwdif.h"
> +
> +#define WIDTH 256
> +
> +#define randomize_buffers(buf0, buf1, mask, count) \
> +for (size_t i; i < count; i++) \
> +buf0[i] = buf1[i] = rnd() & mask
> +
> +void checkasm_check_vf_bwdif(void)
> +{
> +BWDIFContext ctx_8, ctx_10, ctx_16;
> +
> +ff_bwdif_init_filter_line(_8, 8);
> +ff_bwdif_init_filter_line(_10, 10);
> +ff_bwdif_init_filter_line(_16, 16);
> +
> +if (check_func(ctx_8.filter_line, "bwdif8")) {
> +uint8_t prev0[9*WIDTH], prev1[9*WIDTH];
> +uint8_t next0[9*WIDTH], next1[9*WIDTH];
> +uint8_t cur0[9*WIDTH], cur1[9*WIDTH];
> +uint8_t dst0[WIDTH], dst1[WIDTH];
> +
> +declare_func(void, void *dst, void *prev, void *cur, void *next,
> +int w, int prefs, int mrefs, int prefs2, int
> mrefs2,
> +int prefs3, int mrefs3, int prefs4, int mrefs4,
> +int parity, int clip_max);
> +
> +randomize_buffers(prev0, prev1, 0xff, 9*WIDTH);
> +randomize_buffers(next0, next1, 0xff, 9*WIDTH);
> +randomize_buffers(cur0, cur1, 0xff, 9*WIDTH);
> +
> +call_ref(dst0, prev0 + 4*WIDTH, cur0 + 4*WIDTH, next0 + 4*WIDTH,
> WIDTH,
> +WIDTH, -WIDTH, 2*WIDTH, -2*WIDTH, 3*WIDTH, -3*WIDTH,
> 4*WIDTH, -4*WIDTH,
> +0, 0xff);
> +call_new(dst1, prev1 + 4*WIDTH, cur1 + 4*WIDTH, next1 + 4*WIDTH,
> WIDTH,
> +WIDTH, -WIDTH, 2*WIDTH, -2*WIDTH, 3*WIDTH, -3*WIDTH,
> 4*WIDTH, -4*WIDTH,
> +0, 0xff);
> +
> +if (memcmp(dst0, dst1, WIDTH)
> +|| memcmp(prev0, prev1, sizeof prev0)
> +|| memcmp(next0, next1, sizeof next0)
> +|| memcmp(cur0, cur1, sizeof cur0))
> +fail();
> +bench_new(dst1, prev1 + 4*WIDTH, cur1 + 4*WIDTH, next1 + 4*WIDTH,
> WIDTH,
> +WIDTH, -WIDTH, 

Re: [FFmpeg-devel] [PATCH 3/3] avfilter: add avx2 filter_line function for bwdif

[Thomas Mundt]

Hi James,

Am Mo., 20. Feb. 2023 um 20:59 Uhr schrieb James Darnley :

> 2.24x faster (1925±1.3 vs. 859±2.2 decicycles) compared with ssse3
> ---
>  libavfilter/x86/vf_bwdif.asm| 29 -
>  libavfilter/x86/vf_bwdif_init.c | 12 
>  2 files changed, 36 insertions(+), 5 deletions(-)
>
> diff --git a/libavfilter/x86/vf_bwdif.asm b/libavfilter/x86/vf_bwdif.asm
> index 0b453da53b..5cc61435fd 100644
> --- a/libavfilter/x86/vf_bwdif.asm
> +++ b/libavfilter/x86/vf_bwdif.asm
> @@ -26,18 +26,22 @@
>
>  %include "libavutil/x86/x86util.asm"
>
> -SECTION_RODATA
> +SECTION_RODATA 32
>
> -pw_coefhf:  times 4 dw  1016, 5570
> -pw_coefhf1: times 8 dw -3801
> -pw_coefsp:  times 4 dw  5077, -981
> -pw_splfdif: times 4 dw  -768,  768
> +pw_coefhf:  times 8 dw  1016, 5570
> +pw_coefhf1: times 16 dw -3801
> +pw_coefsp:  times 8 dw  5077, -981
> +pw_splfdif: times 8 dw  -768,  768
>
>  SECTION .text
>
>  %macro LOAD8 2
> +%if mmsize == 32
> +pmovzxbw %1, %2
> +%else
>  movh %1, %2
>  punpcklbw%1, m7
> +%endif
>  %endmacro
>
>  %macro LOAD12 2
> @@ -45,8 +49,14 @@ SECTION .text
>  %endmacro
>
>  %macro DISP8 0
> +%if mmsize == 32
> +vextracti128  xm1,m2, 1
> +packuswb  xm2,   xm1
> +movu [dstq], xm2
> +%else
>  packuswb m2, m2
>  movh [dstq], m2
> +%endif
>  %endmacro
>
>  %macro DISP12 0
> @@ -244,8 +254,12 @@ cglobal bwdif_filter_line_12bit, 4, 9, 13, 0, dst,
> prev, cur, next, w, \
>prefs, mrefs, prefs2,
> mrefs2, \
>prefs3, mrefs3, prefs4, \
>mrefs4, parity, clip_max
> +%if mmsize == 32
> +vpbroadcastd m12, DWORD clip_maxm
>

I get a green pattern at bit depths > 8.
Looks good with:
vpbroadcastw m12, WORD clip_maxm

+%else
>  movdm12, DWORD clip_maxm
>  SPLATW  m12, m12, 0
> +%endif
>  %else
>  cglobal bwdif_filter_line_12bit, 4, 6, 8, 80, dst, prev, cur, next, w, \
>prefs, mrefs, prefs2,
> mrefs2, \
> @@ -264,3 +278,8 @@ INIT_XMM ssse3
>  BWDIF
>  INIT_XMM sse2
>  BWDIF
> +
> +%if HAVE_AVX2_EXTERNAL && ARCH_X86_64
> +INIT_YMM avx2
> +BWDIF
> +%endif
> diff --git a/libavfilter/x86/vf_bwdif_init.c
> b/libavfilter/x86/vf_bwdif_init.c
> index ba7bc40c3d..f833318c10 100644
> --- a/libavfilter/x86/vf_bwdif_init.c
> +++ b/libavfilter/x86/vf_bwdif_init.c
> @@ -32,6 +32,10 @@ void ff_bwdif_filter_line_ssse3(void *dst, void *prev,
> void *cur, void *next,
>  int w, int prefs, int mrefs, int prefs2,
>  int mrefs2, int prefs3, int mrefs3, int
> prefs4,
>  int mrefs4, int parity, int clip_max);
> +void ff_bwdif_filter_line_avx2(void *dst, void *prev, void *cur, void
> *next,
> +   int w, int prefs, int mrefs, int prefs2,
> +   int mrefs2, int prefs3, int mrefs3, int
> prefs4,
> +   int mrefs4, int parity, int clip_max);
>
>  void ff_bwdif_filter_line_12bit_sse2(void *dst, void *prev, void *cur,
> void *next,
>   int w, int prefs, int mrefs, int
> prefs2,
> @@ -41,6 +45,10 @@ void ff_bwdif_filter_line_12bit_ssse3(void *dst, void
> *prev, void *cur, void *ne
>int w, int prefs, int mrefs, int
> prefs2,
>int mrefs2, int prefs3, int mrefs3,
> int prefs4,
>int mrefs4, int parity, int
> clip_max);
> +void ff_bwdif_filter_line_12bit_avx2(void *dst, void *prev, void *cur,
> void *next,
> + int w, int prefs, int mrefs, int
> prefs2,
> + int mrefs2, int prefs3, int mrefs3,
> int prefs4,
> + int mrefs4, int parity, int
> clip_max);
>
>  av_cold void ff_bwdif_init_x86(BWDIFContext *bwdif, int bit_depth)
>  {
> @@ -51,10 +59,14 @@ av_cold void ff_bwdif_init_x86(BWDIFContext *bwdif,
> int bit_depth)
>  bwdif->filter_line = ff_bwdif_filter_line_sse2;
>  if (EXTERNAL_SSSE3(cpu_flags))
>  bwdif->filter_line = ff_bwdif_filter_line_ssse3;
> +if (ARCH_X86_64 && EXTERNAL_AVX2(cpu_flags))
> +bwdif->filter_line = ff_bwdif_filter_line_avx2;
>  } else if (bit_depth <= 12) {
>  if (EXTERNAL_SSE2(cpu_flags))
>  bwdif->filter_line = ff_bwdif_filter_line_12bit_sse2;
>  if (EXTERNAL_SSSE3(cpu_flags))
>  bwdif->filter_line = ff_bwdif_filter_line_12bit_ssse3;
> +if (ARCH_X86_64 && EXTERNAL_AVX2(cpu_flags))
> +bwdif->filter_line = ff_bwdif_filter_line_12bit_avx2;
>  }
>  }
> --
> 2.39.1
___

Re: [FFmpeg-devel] [PATCH 1/3] avfilter: move bwdif's filter_line init into a dedicated function

[Thomas Mundt]

Hi James,

James Darnley  schrieb am Mo., 20. Feb. 2023, 13:59:

> ---
>  libavfilter/bwdif.h |  3 ++-
>  libavfilter/vf_bwdif.c  | 13 +
>  libavfilter/x86/vf_bwdif_init.c |  4 +---
>  3 files changed, 12 insertions(+), 8 deletions(-)
>
> diff --git a/libavfilter/bwdif.h b/libavfilter/bwdif.h
> index 889ff772ed..5749345f78 100644
> --- a/libavfilter/bwdif.h
> +++ b/libavfilter/bwdif.h
> @@ -37,6 +37,7 @@ typedef struct BWDIFContext {
>  int parity, int clip_max, int spat);
>  } BWDIFContext;
>
> -void ff_bwdif_init_x86(BWDIFContext *bwdif);
> +void ff_bwdif_init_filter_line(BWDIFContext *bwdif, int bit_depth);
> +void ff_bwdif_init_x86(BWDIFContext *bwdif, int bit_depth);
>
>  #endif /* AVFILTER_BWDIF_H */
> diff --git a/libavfilter/vf_bwdif.c b/libavfilter/vf_bwdif.c
> index 65c617ebb3..34e8c5e234 100644
> --- a/libavfilter/vf_bwdif.c
> +++ b/libavfilter/vf_bwdif.c
> @@ -340,7 +340,14 @@ static int config_props(AVFilterLink *link)
>
>  yadif->csp = av_pix_fmt_desc_get(link->format);
>  yadif->filter = filter;
> -if (yadif->csp->comp[0].depth > 8) {
> +ff_bwdif_init_filter_line(s, yadif->csp->comp[0].depth);
> +
> +return 0;
> +}
> +
> +av_cold void ff_bwdif_init_filter_line(BWDIFContext *s, int bit_depth)
> +{
> +if (bit_depth > 8) {
>  s->filter_intra = filter_intra_16bit;
>  s->filter_line  = filter_line_c_16bit;
>  s->filter_edge  = filter_edge_16bit;
> @@ -351,10 +358,8 @@ static int config_props(AVFilterLink *link)
>  }
>
>  #if ARCH_X86
> -ff_bwdif_init_x86(s);
> +ff_bwdif_init_x86(s, bit_depth);
>  #endif
> -
> -return 0;
>  }
>
>
> diff --git a/libavfilter/x86/vf_bwdif_init.c
> b/libavfilter/x86/vf_bwdif_init.c
> index e24e5cd9b1..ba7bc40c3d 100644
> --- a/libavfilter/x86/vf_bwdif_init.c
> +++ b/libavfilter/x86/vf_bwdif_init.c
> @@ -42,11 +42,9 @@ void ff_bwdif_filter_line_12bit_ssse3(void *dst, void
> *prev, void *cur, void *ne
>int mrefs2, int prefs3, int mrefs3,
> int prefs4,
>int mrefs4, int parity, int
> clip_max);
>
> -av_cold void ff_bwdif_init_x86(BWDIFContext *bwdif)
> +av_cold void ff_bwdif_init_x86(BWDIFContext *bwdif, int bit_depth)
>  {
> -YADIFContext *yadif = >yadif;
>  int cpu_flags = av_get_cpu_flags();
> -int bit_depth = (!yadif->csp) ? 8 : yadif->csp->comp[0].depth;
>
>  if (bit_depth <= 8) {
>  if (EXTERNAL_SSE2(cpu_flags))
> --
> 2.39.1
>

I'm travelling at the moment and can only look at your patch set on my
phone. At first glance it looks good. If you are not in a hurry, I would
test it in two to three weeks when I am back home and have time.

Best Regards,
Thomas

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

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

Re: [FFmpeg-devel] [PATCH 2/2] avfilter/vf_tinterlace: support full-range YUV

[Thomas Mundt]

Am Fr., 9. Dez. 2022 um 01:28 Uhr schrieb Niklas Haas :

> From: Niklas Haas 
>
> This filter, when used in the "pad" mode, currently makes the
> distinction between limited and full range solely by testing for YUVJ
> pixel formats at link setup time. This is deprecated and should be
> improved to perform the detection based on the per-frame metadata.
>
> In order to make this distinction based on color range metadata, which
> is only known at the time of filtering frames, for simplicity, we simply
> allocate two copies of the "black" frame - one for limited range and the
> other for full range metadata. This could be done more dynamically (e.g.
> as-needed or simply by blitting the appropriate pixel value directly),
> but this change is relatively simple and preserves the structure of the
> existing code.
>
> This commit actually fixes a bug in FATE - the new output is correct for
> the first time. The previous md5 ref was of a frame that incorrectly
> combined full-range pixel data with limited-range black fields. The
> corresponding result has been updated.
>
> Signed-off-by: Niklas Haas 
> ---
>  libavfilter/tinterlace.h |  2 +-
>  libavfilter/vf_tinterlace.c  | 26 ++--
>  tests/ref/fate/filter-pixfmts-tinterlace_pad |  2 +-
>  3 files changed, 20 insertions(+), 10 deletions(-)
>
> diff --git a/libavfilter/tinterlace.h b/libavfilter/tinterlace.h
> index 4059ebf81a..37b6c10c08 100644
> --- a/libavfilter/tinterlace.h
> +++ b/libavfilter/tinterlace.h
> @@ -70,7 +70,7 @@ typedef struct TInterlaceContext {
>  int vsub;   ///< chroma vertical subsampling
>  AVFrame *cur;
>  AVFrame *next;
> -uint8_t *black_data[4]; ///< buffer used to fill padded lines
> +uint8_t *black_data[2][4];  ///< buffer used to fill padded lines
> (limited/full)
>  int black_linesize[4];
>  FFDrawContext draw;
>  FFDrawColor color;
> diff --git a/libavfilter/vf_tinterlace.c b/libavfilter/vf_tinterlace.c
> index 7c54861de4..032629279a 100644
> --- a/libavfilter/vf_tinterlace.c
> +++ b/libavfilter/vf_tinterlace.c
> @@ -201,7 +201,8 @@ static av_cold void uninit(AVFilterContext *ctx)
>
>  av_frame_free(>cur );
>  av_frame_free(>next);
> -av_freep(>black_data[0]);
> +av_freep(>black_data[0][0]);
> +av_freep(>black_data[1][0]);
>  }
>
>  static int config_out_props(AVFilterLink *outlink)
> @@ -225,14 +226,22 @@ static int config_out_props(AVFilterLink *outlink)
>  int ret;
>  ff_draw_init(>draw, outlink->format, 0);
>  ff_draw_color(>draw, >color, black);
> -if (ff_fmt_is_in(outlink->format, full_scale_yuvj_pix_fmts))
> -tinterlace->color.comp[0].u8[0] = 0;
> -ret = av_image_alloc(tinterlace->black_data,
> tinterlace->black_linesize,
> +/* limited range */
> +if (!ff_fmt_is_in(outlink->format, full_scale_yuvj_pix_fmts)) {
> +ret = av_image_alloc(tinterlace->black_data[0],
> tinterlace->black_linesize,
> + outlink->w, outlink->h, outlink->format,
> 16);
> +if (ret < 0)
> +return ret;
> +ff_fill_rectangle(>draw, >color,
> tinterlace->black_data[0],
> +  tinterlace->black_linesize, 0, 0,
> outlink->w, outlink->h);
> +}
> +/* full range */
> +tinterlace->color.comp[0].u8[0] = 0;
> +ret = av_image_alloc(tinterlace->black_data[1],
> tinterlace->black_linesize,
>   outlink->w, outlink->h, outlink->format, 16);
>  if (ret < 0)
>  return ret;
> -
> -ff_fill_rectangle(>draw, >color,
> tinterlace->black_data,
> +ff_fill_rectangle(>draw, >color,
> tinterlace->black_data[1],
>tinterlace->black_linesize, 0, 0, outlink->w,
> outlink->h);
>  }
>  if (tinterlace->flags & (TINTERLACE_FLAG_VLPF | TINTERLACE_FLAG_CVLPF)
> @@ -360,7 +369,7 @@ static int filter_frame(AVFilterLink *inlink, AVFrame
> *picref)
>  AVFilterLink *outlink = ctx->outputs[0];
>  TInterlaceContext *tinterlace = ctx->priv;
>  AVFrame *cur, *next, *out;
> -int field, tff, ret;
> +int field, tff, full, ret;
>
>  av_frame_free(>cur);
>  tinterlace->cur  = tinterlace->next;
> @@ -418,6 +427,7 @@ static int filter_frame(AVFilterLink *inlink, AVFrame
> *picref)
>  out->sample_aspect_ratio = av_mul_q(cur->sample_aspect_ratio,
> av_make_q(2, 1));
>
>  field = (1 + outlink->frame_count_in) & 1 ? FIELD_UPPER :
> FIELD_LOWER;
> +full = out->color_range == AVCOL_RANGE_JPEG ||
> ff_fmt_is_in(out->format, full_scale_yuvj_pix_fmts);
>  /* copy upper and lower fields */
>  copy_picture_field(tinterlace, out->data, out->linesize,
> (const uint8_t **)cur->data, cur->linesize,
> @@ -425,7 +435,7 @@ static int filter_frame(AVFilterLink *inlink, AVFrame
> *picref)
> 

Re: [FFmpeg-devel] [PATCH] avfilter/vf_bwdif_cuda: CUDA implementation of bwdif

[Thomas Mundt]

Am Mo., 12. Okt. 2020 um 21:42 Uhr schrieb Philip Langdale <
phil...@overt.org>:

> On Sun, 11 Oct 2020 18:36:42 +0200
> Thomas Mundt  wrote:
>
> > Hi Philip,
> >
> > Am Fr., 9. Okt. 2020 um 18:33 Uhr schrieb Philip Langdale
> >  > >:
> >
> > > I've been sitting on this for a couple of years now, and I figured I
> > > should just send it out. This is what I believe is a conceptually
> > > correct port of bwdif to cuda (modulo edge handling which is not
> > > done in the same way because the conditional checks for edges are
> > > expensive in cuda, but that's the same as for yadif_cuda).
> > >
> > > However, I see glitches in some samples where black or white pixels
> > > appear in white or black areas respectively. This seems like some
> > > sort of under/overflow. I've tried to use the largest cuda types
> > > everywhere, and that did appear to improve things but didn't make
> > > it go away. This is what led to me never sending this diff over the
> > > years, but maybe someone else has insights about this.
> > >
> >
> > I am not familiar with cuda. So here is just one difference, which I
> > noticed compared to the c code.
> > Maybe that is the reason for the glitches.
> >
> > > +
> > > +template
> > > +__inline__ __device__ T filter(T A, T B, T C, T D,
> > > +   T a, T b, T c, T d, T e, T f, T g,
> > > +   T h, T i, T j, T k, T l, T m, T n,
> > > +   int clip_max)
> > > +{
> > > +T final;
> > > +
> > > +int fc = C;
> > > +int fd = (c + l) >> 1;
> > > +int fe = B;
> > >
> >
> > In the following you sometimes use B and C directly and sometimes fc
> > and fe. Is there a reason for this?
>
> Unfortunately, I can't remember. This may have had something to do with
> wanting those calculations to be done with smaller data types, but why
> do that? Switch them did not have any obvious visual effect.
>
> >
> > > +
> > > +int temporal_diff0 = abs(c - l);
> > > +int temporal_diff1 = (abs(g - fc) + abs(f - fe)) >> 1;
> > > +int temporal_diff2 = (abs(i - fc) + abs(h - fe)) >> 1;
> > > +int diff = max3(temporal_diff0 >> 1, temporal_diff1,
> > > temporal_diff2); +
> > > +if (!diff) {
> > > +final = fd;
> > > +} else {
> > > +int fb = ((d + m) >> 1) - fc;
> > > +int ff = ((c + l) >> 1) - fe;
> > >
> >
> > If I don´t miss anything this should be:
> > int ff = ((b + k) >> 1) - fe;
>
> I think you're right. This also doesn't seem to change things
> significantly; the glitches are still there, but that's not surprising.
> This fix would make the non-glitched parts more correct.
>
> Thanks for taking a look. I'll keep banging my head against this one.
>

Could you please point out in the description of the bwdif_cuda filter that
the processing of the top and bottom edges and the first and last field is
different from the bwdif filter. This can lead to glitches in the upper and
lower edges and ghosting effects in the first and last field.

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

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

Re: [FFmpeg-devel] [PATCH] avfilter/vf_bwdif_cuda: CUDA implementation of bwdif

[Thomas Mundt]

Hi Philip,

Am Fr., 9. Okt. 2020 um 18:33 Uhr schrieb Philip Langdale :

> I've been sitting on this for a couple of years now, and I figured I
> should just send it out. This is what I believe is a conceptually
> correct port of bwdif to cuda (modulo edge handling which is not done
> in the same way because the conditional checks for edges are expensive
> in cuda, but that's the same as for yadif_cuda).
>
> However, I see glitches in some samples where black or white pixels
> appear in white or black areas respectively. This seems like some
> sort of under/overflow. I've tried to use the largest cuda types
> everywhere, and that did appear to improve things but didn't make
> it go away. This is what led to me never sending this diff over the
> years, but maybe someone else has insights about this.
>

I am not familiar with cuda. So here is just one difference, which I
noticed compared to the c code.
Maybe that is the reason for the glitches.


> ---
>  configure|   2 +
>  libavfilter/Makefile |   2 +
>  libavfilter/allfilters.c |   1 +
>  libavfilter/vf_bwdif_cuda.c  | 394 +++
>  libavfilter/vf_bwdif_cuda.cu | 290 ++
>  5 files changed, 689 insertions(+)
>  create mode 100644 libavfilter/vf_bwdif_cuda.c
>  create mode 100644 libavfilter/vf_bwdif_cuda.cu
>
> ...

> +
> +template
> +__inline__ __device__ T filter(T A, T B, T C, T D,
> +   T a, T b, T c, T d, T e, T f, T g,
> +   T h, T i, T j, T k, T l, T m, T n,
> +   int clip_max)
> +{
> +T final;
> +
> +int fc = C;
> +int fd = (c + l) >> 1;
> +int fe = B;
>

In the following you sometimes use B and C directly and sometimes fc and
fe. Is there a reason for this?


> +
> +int temporal_diff0 = abs(c - l);
> +int temporal_diff1 = (abs(g - fc) + abs(f - fe)) >> 1;
> +int temporal_diff2 = (abs(i - fc) + abs(h - fe)) >> 1;
> +int diff = max3(temporal_diff0 >> 1, temporal_diff1, temporal_diff2);
> +
> +if (!diff) {
> +final = fd;
> +} else {
> +int fb = ((d + m) >> 1) - fc;
> +int ff = ((c + l) >> 1) - fe;
>

If I don´t miss anything this should be:
int ff = ((b + k) >> 1) - fe;


> +int dc = fd - fc;
> +int de = fd - fe;
> +int mmax = max3(de, dc, min(fb, ff));
> +int mmin = min3(de, dc, max(fb, ff));
> +diff = max3(diff, mmin, -mmax);
> +
> +int interpol;
> +if (abs(fc - fe) > temporal_diff0) {
> +interpol = (((coef_hf[0] * (c + l)
> +- coef_hf[1] * (d + m + b + k)
> ++ coef_hf[2] * (e + n + a + j)) >> 2)
> ++ coef_lf[0] * (C + B) - coef_lf[1] * (D + A)) >> 13;
> +} else {
> +interpol = (coef_sp[0] * (C + B) - coef_sp[1] * (D + A)) >>
> 13;
> +}
> +if (interpol > fd + diff) {
> +interpol = fd + diff;
> +} else if (interpol < fd - diff) {
> +interpol = fd - diff;
> +}
> +final = clip(interpol, 0, clip_max);
> +}
> +
> +return final;
> +}
> +
> +template
> +__inline__ __device__ void bwdif_single(T *dst,
> +cudaTextureObject_t prev,
> +cudaTextureObject_t cur,
> +cudaTextureObject_t next,
> +int dst_width, int dst_height,
> int dst_pitch,
> +int src_width, int src_height,
> +int parity, int tff, bool
> skip_spatial_check,
> +int clip_max)
> +{
> +// Identify location
> +int xo = blockIdx.x * blockDim.x + threadIdx.x;
> +int yo = blockIdx.y * blockDim.y + threadIdx.y;
> +
> +if (xo >= dst_width || yo >= dst_height) {
> +return;
> +}
> +
> +// Don't modify the primary field
> +if (yo % 2 == parity) {
> +  dst[yo*dst_pitch+xo] = tex2D(cur, xo, yo);
> +  return;
> +}
> +
> +T A = tex2D(cur, xo, yo + 3);
> +T B = tex2D(cur, xo, yo + 1);
> +T C = tex2D(cur, xo, yo - 1);
> +T D = tex2D(cur, xo, yo - 3);
> +
> +// Calculate temporal prediction
> +int is_second_field = !(parity ^ tff);
> +
> +cudaTextureObject_t prev2 = prev;
> +cudaTextureObject_t prev1 = is_second_field ? cur : prev;
> +cudaTextureObject_t next1 = is_second_field ? next : cur;
> +cudaTextureObject_t next2 = next;
> +
> +T a = tex2D(prev2, xo,  yo + 4);
> +T b = tex2D(prev2, xo,  yo + 2);
> +T c = tex2D(prev2, xo,  yo + 0);
> +T d = tex2D(prev2, xo,  yo - 2);
> +T e = tex2D(prev2, xo,  yo - 4);
> +T f = tex2D(prev1, xo,  yo + 1);
> +T g = tex2D(prev1, xo,  yo - 1);
> +T h = tex2D(next1, xo,  yo + 1);
> +T i = tex2D(next1, xo,  yo - 1);
> +T j = tex2D(next2, xo,  yo + 

Re: [FFmpeg-devel] [PATCH] avfilter/vf_bwdif: fix heap-buffer overflow

[Thomas Mundt]

Am So., 13. Okt. 2019 um 23:22 Uhr schrieb Paul B Mahol :

> Fixes #8261
>
> Signed-off-by: Paul B Mahol 
> ---
>  libavfilter/vf_bwdif.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/libavfilter/vf_bwdif.c b/libavfilter/vf_bwdif.c
> index 37165584cf..b6aed7a450 100644
> --- a/libavfilter/vf_bwdif.c
> +++ b/libavfilter/vf_bwdif.c
> @@ -343,8 +343,8 @@ static int config_props(AVFilterLink *link)
>  if(yadif->mode&1)
>  link->frame_rate = av_mul_q(link->src->inputs[0]->frame_rate,
> (AVRational){2,1});
>
> -if (link->w < 3 || link->h < 3) {
> -av_log(ctx, AV_LOG_ERROR, "Video of less than 3 columns or lines
> is not supported\n");
> +if (link->w < 3 || link->h < 4) {
> +av_log(ctx, AV_LOG_ERROR, "Video of less than 3 columns or 4
> lines is not supported\n");
>  return AVERROR(EINVAL);
>  }


lgtm, thanks.

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

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

Re: [FFmpeg-devel] [PATCH] libavformat/mxfenc: Allow more bitrates for NTSC IMX50

[Thomas Mundt]

Am Fr., 16. Aug. 2019 um 23:31 Uhr schrieb Tomas Härdin :

> tor 2019-08-15 klockan 13:55 +0200 skrev Thomas Mundt:
> > Am Do., 15. Aug. 2019 um 11:01 Uhr schrieb Tomas Härdin <
> tjop...@acc.umu.se
> > > :
> > > ons 2019-08-14 klockan 22:18 +0200 skrev Thomas Mundt:
> > > > Hi Tomas,
> > > >
> > > > Am Mi., 14. Aug. 2019 um 12:42 Uhr schrieb Tomas Härdin <
> > > tjop...@acc.umu.se
> > > > > :
> > > > > tis 2019-08-13 klockan 22:03 +0200 skrev Thomas Mundt:
> > > > > > Hi,
> > > > > >
> > > > > > attached patch fixes ticket #8077.
> > > > > > Please comment.
> > > > >
> > > > > Probably OK, bitrates lower than 5000 are fine in D-10
> according to
> > > > > S356m.
> > > > >
> > > > > > } else if ((sc->video_bit_rate >= 4840) &&
> (sc->video_bit_rate <=
> > > > > > 5000) && (mxf->time_base.den != 25)) {
> > > > >
> > > > > You could drop the extra parentheses, else it should be fine.
> > > > >
> > > >
> > > > New patch attached.
> > >
> > > Looks OK. I'll push in a few days if no one else has any comments
> > >
> >
> > Thanks. Would you mind porting it to branches 4.1 and 4.2?
>
> I'm not quite sure what the process is for that. I have confirmed that
> the problem exists in 4.1 and 4.2 and that your patch fixes it.
>
> I think we also might want to put a note somewhere in the documentation
> how to make NTSC IMX50 files.
>

I can give you the parameters that I use for IMX50. Not sure if these are
the best. Got the intra matrix values from an original imx file.

NTSC: -c:v mpeg2video -pix_fmt yuv422p -aspect 16:9 -top 1 -flags
+ildct+ilme+low_delay -color_range tv -color_trc smpte170m -color_primaries
smpte170m -colorspace smpte170m -chroma_sample_location topleft
-signal_standard bt601 -dc 10 -intra_vlc 1 -non_linear_quant 1 -ps 1 -g 1
-qscale:v 1 -qmin 1 -qmax 12 -b:v 4841 -minrate 4841 -maxrate
4841 -bufsize 1668329 -rc_init_occupancy 1668329 -rc_min_vbv_use 1
-rc_max_vbv_use 1 -profile:v 0 -level:v 5 -intra_matrix
8,16,16,17,19,22,23,31,16,16,17,19,20,23,29,29,19,17,19,22,19,25,28,35,17,19,19,20,25,28,25,33,17,19,22,25,26,25,31,31,17,19,17,20,26,28,35,36,19,19,19,20,22,29,32,35,16,17,19,22,25,31,28,45

PAL: -c:v mpeg2video -pix_fmt yuv422p -aspect 16:9 -top 1 -flags
+ildct+ilme+low_delay -color_range tv -color_trc smpte170m -color_primaries
bt470bg -colorspace bt470bg -chroma_sample_location topleft
-signal_standard bt601 -dc 10 -intra_vlc 1 -non_linear_quant 1 -ps 1 -g 1
-qscale:v 1 -qmin 1 -qmax 12 -b:v 5000 -minrate 5000 -maxrate
5000 -bufsize 200 -rc_init_occupancy 200 -rc_min_vbv_use 1
-rc_max_vbv_use 1 -profile:v 0 -level:v 5 -intra_matrix
8,16,16,17,19,22,23,31,16,16,17,19,20,23,29,29,19,17,19,22,19,25,28,35,17,19,19,20,25,28,25,33,17,19,22,25,26,25,31,31,17,19,17,20,26,28,35,36,19,19,19,20,22,29,32,35,16,17,19,22,25,31,28,45

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

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

Re: [FFmpeg-devel] [PATCH] libavformat/mxfenc: Allow more bitrates for NTSC IMX50

[Thomas Mundt]

Am Do., 15. Aug. 2019 um 11:01 Uhr schrieb Tomas Härdin :

> ons 2019-08-14 klockan 22:18 +0200 skrev Thomas Mundt:
> > Hi Tomas,
> >
> > Am Mi., 14. Aug. 2019 um 12:42 Uhr schrieb Tomas Härdin <
> tjop...@acc.umu.se
> > > :
> > > tis 2019-08-13 klockan 22:03 +0200 skrev Thomas Mundt:
> > > > Hi,
> > > >
> > > > attached patch fixes ticket #8077.
> > > > Please comment.
> > >
> > > Probably OK, bitrates lower than 5000 are fine in D-10 according to
> > > S356m.
> > >
> > > > } else if ((sc->video_bit_rate >= 4840) && (sc->video_bit_rate <=
> > > > 5000) && (mxf->time_base.den != 25)) {
> > >
> > > You could drop the extra parentheses, else it should be fine.
> > >
> >
> > New patch attached.
>
> Looks OK. I'll push in a few days if no one else has any comments
>

Thanks. Would you mind porting it to branches 4.1 and 4.2?


> > > The real fix is of course to add an explicit CBR mode to lavc, but
> > > that's a bit more involved than this fix.
> >
> > IMX is being used less and less. Maybe it´s not worth the effort.
>
> It's not the only case where CBR MPEG-2 is desireable I think.
> Certainly outside my concern however. Maybe something for x262? Since
> x264 has such a mode I wouldn't be surprised if x262 does as well.
>

Yeah, a CBR option would definitely make it easier for users.
So far I have not dealt with x262.

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

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

Re: [FFmpeg-devel] [PATCH] libavformat/mxfenc: Allow more bitrates for NTSC IMX50

[Thomas Mundt]

Hi Tomas,

Am Mi., 14. Aug. 2019 um 12:42 Uhr schrieb Tomas Härdin :

> tis 2019-08-13 klockan 22:03 +0200 skrev Thomas Mundt:
> > Hi,
> >
> > attached patch fixes ticket #8077.
> > Please comment.
>
> Probably OK, bitrates lower than 5000 are fine in D-10 according to
> S356m.
>
> > } else if ((sc->video_bit_rate >= 4840) && (sc->video_bit_rate <=
> > 5000) && (mxf->time_base.den != 25)) {
>
> You could drop the extra parentheses, else it should be fine.
>

New patch attached.

The real fix is of course to add an explicit CBR mode to lavc, but
> that's a bit more involved than this fix.


IMX is being used less and less. Maybe it´s not worth the effort.

Regards,
Thomas


0001-libavformat-mxfenc-Allow-more-bitrates-for-NTSC-IMX5.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

[FFmpeg-devel] [PATCH] libavformat/mxfenc: Allow more bitrates for NTSC IMX50

[Thomas Mundt]

Hi,

attached patch fixes ticket #8077.
Please comment.

Regards,
Thomas


0001-libavformat-mxfenc-Allow-more-bitrates-for-NTSC-IMX5.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [PATCH] avformat/mxfenc: support XAVC long gop

[Thomas Mundt]

Hi Baptiste,

Am Di., 14. Mai 2019 um 18:59 Uhr schrieb Baptiste Coudurier <
baptiste.coudur...@gmail.com>:

> ---
>  libavformat/Makefile |   2 +-
>  libavformat/avc.c| 186 +
>  libavformat/avc.h|  15 +++
>  libavformat/hevc.c   |  36 +---
>  libavformat/mxf.h|   1 +
>  libavformat/mxfenc.c | 213 ++-
>  6 files changed, 372 insertions(+), 81 deletions(-)
>
> diff --git a/libavformat/Makefile b/libavformat/Makefile
> index 99be60d184..df87c54a58 100644
> --- a/libavformat/Makefile
> +++ b/libavformat/Makefile
> @@ -339,7 +339,7 @@ OBJS-$(CONFIG_MUSX_DEMUXER)  += musx.o
>  OBJS-$(CONFIG_MV_DEMUXER)+= mvdec.o
>  OBJS-$(CONFIG_MVI_DEMUXER)   += mvi.o
>  OBJS-$(CONFIG_MXF_DEMUXER)   += mxfdec.o mxf.o
> -OBJS-$(CONFIG_MXF_MUXER) += mxfenc.o mxf.o
> audiointerleave.o
> +OBJS-$(CONFIG_MXF_MUXER) += mxfenc.o mxf.o
> audiointerleave.o avc.o
>  OBJS-$(CONFIG_MXG_DEMUXER)   += mxg.o
>  OBJS-$(CONFIG_NC_DEMUXER)+= ncdec.o
>  OBJS-$(CONFIG_NISTSPHERE_DEMUXER)+= nistspheredec.o pcm.o
> diff --git a/libavformat/avc.c b/libavformat/avc.c
> index ec50033a04..a041e84357 100644
> --- a/libavformat/avc.c
> +++ b/libavformat/avc.c
> @@ -21,6 +21,7 @@
>
>  #include "libavutil/intreadwrite.h"
>  #include "libavcodec/h264.h"
> +#include "libavcodec/get_bits.h"
>  #include "avformat.h"
>  #include "avio.h"
>  #include "avc.h"
> @@ -241,3 +242,188 @@ const uint8_t *ff_avc_mp4_find_startcode(const
> uint8_t *start,
>
>  return start + res;
>  }
> +
> +uint8_t *ff_nal_unit_extract_rbsp(const uint8_t *src, uint32_t src_len,
> +  uint32_t *dst_len, int header_len)
> +{
> +uint8_t *dst;
> +uint32_t i, len;
> +
> +dst = av_malloc(src_len + AV_INPUT_BUFFER_PADDING_SIZE);
> +if (!dst)
> +return NULL;
> +
> +/* NAL unit header */
> +i = len = 0;
> +while (i < header_len && i < src_len)
> +dst[len++] = src[i++];
> +
> +while (i + 2 < src_len)
> +if (!src[i] && !src[i + 1] && src[i + 2] == 3) {
> +dst[len++] = src[i++];
> +dst[len++] = src[i++];
> +i++; // remove emulation_prevention_three_byte
> +} else
> +dst[len++] = src[i++];
> +
> +while (i < src_len)
> +dst[len++] = src[i++];
> +
> +memset(dst + len, 0, AV_INPUT_BUFFER_PADDING_SIZE);
> +
> +*dst_len = len;
> +return dst;
> +}
> +
> +static const AVRational avc_sample_aspect_ratio[17] = {
> +{   0,  1 },
> +{   1,  1 },
> +{  12, 11 },
> +{  10, 11 },
> +{  16, 11 },
> +{  40, 33 },
> +{  24, 11 },
> +{  20, 11 },
> +{  32, 11 },
> +{  80, 33 },
> +{  18, 11 },
> +{  15, 11 },
> +{  64, 33 },
> +{ 160, 99 },
> +{   4,  3 },
> +{   3,  2 },
> +{   2,  1 },
> +};
> +
> +static inline int get_ue_golomb(GetBitContext *gb) {
> +int i;
> +for (i = 0; i < 32 && !get_bits1(gb); i++)
> +;
> +return get_bitsz(gb, i) + (1 << i) - 1;
> +}
> +
> +static inline int get_se_golomb(GetBitContext *gb) {
> +int v = get_ue_golomb(gb) + 1;
> +int sign = -(v & 1);
> +return ((v >> 1) ^ sign) - sign;
> +}
> +
> +H264SequenceParameterSet *ff_avc_decode_sps(const uint8_t *buf, int
> buf_size)
> +{
> +int i, j, ret, rbsp_size, aspect_ratio_idc, pic_order_cnt_type;
> +int num_ref_frames_in_pic_order_cnt_cycle;
> +int delta_scale, lastScale = 8, nextScale = 8;
> +int sizeOfScalingList;
> +H264SequenceParameterSet *sps = NULL;
> +GetBitContext gb;
> +uint8_t *rbsp_buf;
> +
> +rbsp_buf = ff_nal_unit_extract_rbsp(buf, buf_size, _size, 0);
> +if (!rbsp_buf)
> +return NULL;
> +
> +ret = init_get_bits8(, rbsp_buf, rbsp_size);
> +if (ret < 0)
> +goto end;
> +
> +sps = av_mallocz(sizeof(*sps));
> +if (!sps)
> +goto end;
> +
> +sps->profile_idc = get_bits(, 8);
> +sps->constraint_set_flags |= get_bits1() << 0; //
> constraint_set0_flag
> +sps->constraint_set_flags |= get_bits1() << 1; //
> constraint_set1_flag
> +sps->constraint_set_flags |= get_bits1() << 2; //
> constraint_set2_flag
> +sps->constraint_set_flags |= get_bits1() << 3; //
> constraint_set3_flag
> +sps->constraint_set_flags |= get_bits1() << 4; //
> constraint_set4_flag
> +sps->constraint_set_flags |= get_bits1() << 5; //
> constraint_set5_flag
> +skip_bits(, 2); // reserved_zero_2bits
> +sps->level_idc = get_bits(, 8);
> +sps->id = get_ue_golomb();
> +
> +if (sps->profile_idc == 100 || sps->profile_idc == 110 ||
> +sps->profile_idc == 122 || sps->profile_idc == 244 ||
> sps->profile_idc ==  44 ||
> +sps->profile_idc ==  83 || sps->profile_idc ==  86 ||
> sps->profile_idc == 118 ||
> +sps->profile_idc == 128 || sps->profile_idc == 138 ||
> 

Re: [FFmpeg-devel] [PATCH] avformat/mxfenc: support XAVC long gop

[Thomas Mundt]

Hi Baptiste,

Am Di., 14. Mai 2019 um 00:33 Uhr schrieb Baptiste Coudurier <
baptiste.coudur...@gmail.com>:

> ---
>  libavformat/Makefile |   2 +-
>  libavformat/avc.c| 186 +
>  libavformat/avc.h|  15 +++
>  libavformat/hevc.c   |  36 +---
>  libavformat/mxf.h|   1 +
>  libavformat/mxfenc.c | 213 ++-
>  6 files changed, 372 insertions(+), 81 deletions(-)
>
> diff --git a/libavformat/Makefile b/libavformat/Makefile
> index 99be60d184..df87c54a58 100644
> --- a/libavformat/Makefile
> +++ b/libavformat/Makefile
> @@ -339,7 +339,7 @@ OBJS-$(CONFIG_MUSX_DEMUXER)  += musx.o
>  OBJS-$(CONFIG_MV_DEMUXER)+= mvdec.o
>  OBJS-$(CONFIG_MVI_DEMUXER)   += mvi.o
>  OBJS-$(CONFIG_MXF_DEMUXER)   += mxfdec.o mxf.o
> -OBJS-$(CONFIG_MXF_MUXER) += mxfenc.o mxf.o
> audiointerleave.o
> +OBJS-$(CONFIG_MXF_MUXER) += mxfenc.o mxf.o
> audiointerleave.o avc.o
>  OBJS-$(CONFIG_MXG_DEMUXER)   += mxg.o
>  OBJS-$(CONFIG_NC_DEMUXER)+= ncdec.o
>  OBJS-$(CONFIG_NISTSPHERE_DEMUXER)+= nistspheredec.o pcm.o
> diff --git a/libavformat/avc.c b/libavformat/avc.c
> index ec50033a04..a041e84357 100644
> --- a/libavformat/avc.c
> +++ b/libavformat/avc.c
> @@ -21,6 +21,7 @@
>
>  #include "libavutil/intreadwrite.h"
>  #include "libavcodec/h264.h"
> +#include "libavcodec/get_bits.h"
>  #include "avformat.h"
>  #include "avio.h"
>  #include "avc.h"
> @@ -241,3 +242,188 @@ const uint8_t *ff_avc_mp4_find_startcode(const
> uint8_t *start,
>
>  return start + res;
>  }
> +
> +uint8_t *ff_nal_unit_extract_rbsp(const uint8_t *src, uint32_t src_len,
> +  uint32_t *dst_len, int header_len)
> +{
> +uint8_t *dst;
> +uint32_t i, len;
> +
> +dst = av_malloc(src_len + AV_INPUT_BUFFER_PADDING_SIZE);
> +if (!dst)
> +return NULL;
> +
> +/* NAL unit header */
> +i = len = 0;
> +while (i < header_len && i < src_len)
> +dst[len++] = src[i++];
> +
> +while (i + 2 < src_len)
> +if (!src[i] && !src[i + 1] && src[i + 2] == 3) {
> +dst[len++] = src[i++];
> +dst[len++] = src[i++];
> +i++; // remove emulation_prevention_three_byte
> +} else
> +dst[len++] = src[i++];
> +
> +while (i < src_len)
> +dst[len++] = src[i++];
> +
> +memset(dst + len, 0, AV_INPUT_BUFFER_PADDING_SIZE);
> +
> +*dst_len = len;
> +return dst;
> +}
> +
> +static const AVRational avc_sample_aspect_ratio[17] = {
> +{   0,  1 },
> +{   1,  1 },
> +{  12, 11 },
> +{  10, 11 },
> +{  16, 11 },
> +{  40, 33 },
> +{  24, 11 },
> +{  20, 11 },
> +{  32, 11 },
> +{  80, 33 },
> +{  18, 11 },
> +{  15, 11 },
> +{  64, 33 },
> +{ 160, 99 },
> +{   4,  3 },
> +{   3,  2 },
> +{   2,  1 },
> +};
> +
> +static inline int get_ue_golomb(GetBitContext *gb) {
> +int i;
> +for (i = 0; i < 32 && !get_bits1(gb); i++)
> +;
> +return get_bitsz(gb, i) + (1 << i) - 1;
> +}
> +
> +static inline int get_se_golomb(GetBitContext *gb) {
> +int v = get_ue_golomb(gb) + 1;
> +int sign = -(v & 1);
> +return ((v >> 1) ^ sign) - sign;
> +}
> +
> +H264SequenceParameterSet *ff_avc_decode_sps(const uint8_t *buf, int
> buf_size)
> +{
> +int i, j, ret, rbsp_size, aspect_ratio_idc, pic_order_cnt_type;
> +int num_ref_frames_in_pic_order_cnt_cycle;
> +int delta_scale, lastScale = 8, nextScale = 8;
> +int sizeOfScalingList;
> +H264SequenceParameterSet *sps = NULL;
> +GetBitContext gb;
> +uint8_t *rbsp_buf;
> +
> +rbsp_buf = ff_nal_unit_extract_rbsp(buf, buf_size, _size, 0);
> +if (!rbsp_buf)
> +return NULL;
> +
> +ret = init_get_bits8(, rbsp_buf, rbsp_size);
> +if (ret < 0)
> +goto end;
> +
> +sps = av_mallocz(sizeof(*sps));
> +if (!sps)
> +goto end;
> +
> +sps->profile_idc = get_bits(, 8);
> +sps->constraint_set_flags |= get_bits1() << 0; //
> constraint_set0_flag
> +sps->constraint_set_flags |= get_bits1() << 1; //
> constraint_set1_flag
> +sps->constraint_set_flags |= get_bits1() << 2; //
> constraint_set2_flag
> +sps->constraint_set_flags |= get_bits1() << 3; //
> constraint_set3_flag
> +sps->constraint_set_flags |= get_bits1() << 4; //
> constraint_set4_flag
> +sps->constraint_set_flags |= get_bits1() << 5; //
> constraint_set5_flag
> +skip_bits(, 2); // reserved_zero_2bits
> +sps->level_idc = get_bits(, 8);
> +sps->id = get_ue_golomb();
> +
> +if (sps->profile_idc == 100 || sps->profile_idc == 110 ||
> +sps->profile_idc == 122 || sps->profile_idc == 244 ||
> sps->profile_idc ==  44 ||
> +sps->profile_idc ==  83 || sps->profile_idc ==  86 ||
> sps->profile_idc == 118 ||
> +sps->profile_idc == 128 || sps->profile_idc == 138 ||
> 

Re: [FFmpeg-devel] [PATCH] avformat/mxfenc: support XAVC long gop

[Thomas Mundt]

Hi Baptiste,

Am Fr., 10. Mai 2019 um 17:51 Uhr schrieb Baptiste Coudurier <
baptiste.coudur...@gmail.com>:

> ---
>  libavformat/Makefile |   2 +-
>  libavformat/avc.c| 188 ++
>  libavformat/avc.h|  15 +++
>  libavformat/hevc.c   |  36 +---
>  libavformat/mxf.h|   1 +
>  libavformat/mxfenc.c | 213 ++-
>  6 files changed, 374 insertions(+), 81 deletions(-)
> [...]

+static const MXFLocalTagPair mxf_avc_subdescriptor_local_tags[] = {
> +{ 0x8100,
> {0x06,0x0E,0x2B,0x34,0x01,0x01,0x01,0x09,0x06,0x01,0x01,0x04,0x06,0x10,0x00,0x00}},
> /* SubDescriptors */
> +{ 0x8200,
> {0x06,0x0E,0x2B,0x34,0x01,0x01,0x01,0x0E,0x04,0x01,0x06,0x06,0x01,0x0E,0x00,0x00}},
> /* AVC Decoding Delay */
> +{ 0x8201,
> {0x06,0x0E,0x2B,0x34,0x01,0x01,0x01,0x0E,0x04,0x01,0x06,0x06,0x01,0x0A,0x00,0x00}},
> /* AVC Profile */
> +{ 0x8202,
> {0x06,0x0E,0x2B,0x34,0x01,0x01,0x01,0x0E,0x04,0x01,0x06,0x06,0x01,0x0D,0x00,0x00}},
> /* AVC Level */
> +};
> +
> [...]
> +static void mxf_write_avc_subdesc(AVFormatContext *s, AVStream *st)
> +{
> +AVIOContext *pb = s->pb;
> +int64_t pos;
> +
> +avio_write(pb, mxf_avc_subdescriptor_key, 16);
> +klv_encode_ber4_length(pb, 0);
> +pos = avio_tell(pb);
> +
> +mxf_write_local_tag(pb, 16, 0x3C0A);
> +mxf_write_uuid(pb, AVCSubDescriptor, 0);
> +
> +mxf_write_local_tag(pb, 1, 0x8200);
> +avio_w8(pb, 0xFF); // AVC Decoding Delay, unknown
> +
> +mxf_write_local_tag(pb, 1, 0x8201);
> +avio_w8(pb, st->codecpar->profile); // AVC Profile
> +
> +mxf_write_local_tag(pb, 1, 0x8202);
> +avio_w8(pb, st->codecpar->level); // AVC Level
> +
> +mxf_update_klv_size(s->pb, pos);
> +}
>

Other MXF muxers, e.g. bmxlib, also write the avc profile constraint tag
when the avc subdescriptor is used. At least MediaInfo detects intra coded
files as long gop otherwise.

FFmpeg crashes with this patch when I try to remux AVC Intra files without
SPS/PPS header.
Tested on Windows 7. Compiled with msys2/gcc7.3.0 x86-32bit.
Command: ffmpeg -i AVCI100_Test.mxf -c:v copy out.mxf
Test file:
https://www.mediafire.com/file/n0oi50u39yi3qpr/AVCI100_Test.mxf/file

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

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

Re: [FFmpeg-devel] [PATCH 2/2] avformat/mxfenc: support XAVC long gop

[Thomas Mundt]

Hi Baptiste,

Am Mi., 10. Apr. 2019 um 00:29 Uhr schrieb Baptiste Coudurier <
baptiste.coudur...@gmail.com>:

> Hi Thomas, I hope you are doing well
>
> > On Apr 4, 2019, at 7:27 AM, Thomas Mundt  wrote:
> >
> > Hi Baptiste,
> >
> > […]
> > For RP2027 Class 100 1080/50i I still get the error: frame size does not
> > match index unit size, 568832 != 0
> > I used the following command:
> > ffmpeg -f lavfi -i testsrc=size=1920x1080:rate=50 -vf interlace -c:v
> > libx264 -pix_fmt yuv422p10 -flags +ildct+ilme -avcintra-class 100
> > -color_primaries bt709 -color_trc bt709 -colorspace bt709 -x264-params
> >
> overscan="crop":videoformat="component":fps=25/1:interlaced=1:tff=1:force-cfr=1
> > -t 1 avci.mxf
>
> I see, that’s the switch to CBR index.
>

Works with you latest patch.


> > Also I encoded AVC High 422 Intra with the following command:
> > ffmpeg lavfi -i testsrc=size=1920x1080:rate=50 -c:v libx264 -pix_fmt
> > yuv422p -x264-params keyint=1 -t 1 avc.mxf
> > Without your patch MediaInfo shows Format profile: High 4:2:2 Intra@L4.2.
> > With your patch MediaInfo shows Format profile: High 4:2:2@L4.2 and
> > Format_Profile_Original: High 4:2:2 Intra@L4.2.
> > According to the MediaInfo documentation, the additional
> > "Format_Profile_Original" is shown when two format profile infomations
> are
> > found that do not match.
> >
>
> Muxer uses ….32.30.01 UID which is High 422 Intra according to specs:
>
> urn:smpte:ul:060e2b34.0401010a.04010202.01323001LEAF
> H.264/MPEG-4 AVC High 422 Intra Profile Unconstrained CodingIdentifies
> H.264/MPEG-4 AVC High 422 Intra Profile Unconstrained Coding
>
> So I’m not sure what media info is doing here.
>

I looked a little deeper into MediaInfo code. If the avc subdescriptor is
used, MediaInfo expects that in addition to profile and level, the profile
constraint is also set for intra coding.
Other MXF muxer, e.g. bmxlib, also set the profile constraint in the avc
subdescriptor.

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

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

Re: [FFmpeg-devel] [PATCH 2/2] avformat/mxfenc: support XAVC long gop

[Thomas Mundt]

Hi Baptiste,

Am Mi., 3. Apr. 2019 um 11:23 Uhr schrieb Baptiste Coudurier <
baptiste.coudur...@gmail.com>:

> ---
>  libavformat/mxf.h|   1 +
>  libavformat/mxfenc.c | 197 ---
>  2 files changed, 147 insertions(+), 51 deletions(-)
>
> diff --git a/libavformat/mxf.h b/libavformat/mxf.h
> index 4394450dea..f32124f772 100644
> --- a/libavformat/mxf.h
> +++ b/libavformat/mxf.h
> @@ -48,6 +48,7 @@ enum MXFMetadataSetType {
>  EssenceGroup,
>  TaggedValue,
>  TapeDescriptor,
> +AVCSubDescriptor,
>  };
>
>  enum MXFFrameLayout {
> diff --git a/libavformat/mxfenc.c b/libavformat/mxfenc.c
> index 8c6db94865..1f865a0ad1 100644
> --- a/libavformat/mxfenc.c
> +++ b/libavformat/mxfenc.c
> @@ -49,7 +49,10 @@
>  #include "libavcodec/bytestream.h"
>  #include "libavcodec/dnxhddata.h"
>  #include "libavcodec/dv_profile.h"
> -#include "libavcodec/h264.h"
> +#include "libavcodec/golomb.h"
> +#include "libavcodec/h264data.h"
> +#include "libavcodec/h264_ps.h"
> +#include "libavcodec/h2645_parse.h"
>  #include "libavcodec/internal.h"
>  #include "audiointerleave.h"
>  #include "avformat.h"
> @@ -99,6 +102,7 @@ typedef struct MXFStreamContext {
>  int max_gop; ///< maximum gop size, used by mpeg-2
> descriptor
>  int b_picture_count; ///< maximum number of consecutive b
> pictures, used in mpeg-2 descriptor
>  int low_delay;   ///< low delay, used in mpeg-2 descriptor
> +int avc_intra;
>  } MXFStreamContext;
>
>  typedef struct MXFContainerEssenceEntry {
> @@ -167,6 +171,7 @@ static const struct {
>  static void mxf_write_wav_desc(AVFormatContext *s, AVStream *st);
>  static void mxf_write_aes3_desc(AVFormatContext *s, AVStream *st);
>  static void mxf_write_mpegvideo_desc(AVFormatContext *s, AVStream *st);
> +static void mxf_write_h264_desc(AVFormatContext *s, AVStream *st);
>  static void mxf_write_cdci_desc(AVFormatContext *s, AVStream *st);
>  static void mxf_write_generic_sound_desc(AVFormatContext *s, AVStream
> *st);
>  static void mxf_write_s436m_anc_desc(AVFormatContext *s, AVStream *st);
> @@ -310,7 +315,7 @@ static const MXFContainerEssenceEntry
> mxf_essence_container_uls[] = {
>  { {
> 0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x0a,0x0D,0x01,0x03,0x01,0x02,0x10,0x60,0x01
> },
>{
> 0x06,0x0E,0x2B,0x34,0x01,0x02,0x01,0x01,0x0D,0x01,0x03,0x01,0x15,0x01,0x05,0x00
> },
>{
> 0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x0a,0x04,0x01,0x02,0x02,0x01,0x00,0x00,0x00
> },
> -  mxf_write_mpegvideo_desc },
> +  mxf_write_h264_desc },
>  // S436M ANC
>  { {
> 0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x0a,0x0D,0x01,0x03,0x01,0x02,0x0e,0x00,0x00
> },
>{
> 0x06,0x0E,0x2B,0x34,0x01,0x02,0x01,0x01,0x0D,0x01,0x03,0x01,0x17,0x01,0x02,0x00
> },
> @@ -498,6 +503,12 @@ static const MXFLocalTagPair mxf_local_tag_batch[] = {
>  { 0x8006,
> {0x06,0x0E,0x2B,0x34,0x01,0x01,0x01,0x05,0x04,0x01,0x06,0x02,0x01,0x08,0x00,0x00}},
> /* MaxGOP */
>  { 0x8007,
> {0x06,0x0E,0x2B,0x34,0x01,0x01,0x01,0x05,0x04,0x01,0x06,0x02,0x01,0x0A,0x00,0x00}},
> /* ProfileAndLevel */
>  { 0x8008,
> {0x06,0x0E,0x2B,0x34,0x01,0x01,0x01,0x05,0x04,0x01,0x06,0x02,0x01,0x09,0x00,0x00}},
> /* BPictureCount */
> +// Generic Descriptor
> +{ 0x8100,
> {0x06,0x0E,0x2B,0x34,0x01,0x01,0x01,0x09,0x06,0x01,0x01,0x04,0x06,0x10,0x00,0x00}},
> /* SubDescriptors */
> +// AVC SubDescriptor
> +{ 0x8200,
> {0x06,0x0E,0x2B,0x34,0x01,0x01,0x01,0x0E,0x04,0x01,0x06,0x06,0x01,0x0E,0x00,0x00}},
> /* AVC Decoding Delay */
> +{ 0x8201,
> {0x06,0x0E,0x2B,0x34,0x01,0x01,0x01,0x0E,0x04,0x01,0x06,0x06,0x01,0x0A,0x00,0x00}},
> /* AVC Profile */
> +{ 0x8202,
> {0x06,0x0E,0x2B,0x34,0x01,0x01,0x01,0x0E,0x04,0x01,0x06,0x06,0x01,0x0D,0x00,0x00}},
> /* AVC Level */
>  // Wave Audio Essence Descriptor
>  { 0x3D09,
> {0x06,0x0E,0x2B,0x34,0x01,0x01,0x01,0x05,0x04,0x02,0x03,0x03,0x05,0x00,0x00,0x00}},
> /* Average Bytes Per Second */
>  { 0x3D0A,
> {0x06,0x0E,0x2B,0x34,0x01,0x01,0x01,0x05,0x04,0x02,0x03,0x02,0x01,0x00,0x00,0x00}},
> /* Block Align */
> @@ -1126,6 +1137,8 @@ static const UID mxf_aes3_descriptor_key  = {
> 0x06,0x0E,0x2B,0x34,0x02,0x53,
>  static const UID mxf_cdci_descriptor_key  = {
> 0x06,0x0E,0x2B,0x34,0x02,0x53,0x01,0x01,0x0D,0x01,0x01,0x01,0x01,0x01,0x28,0x00
> };
>  static const UID mxf_generic_sound_descriptor_key = {
> 0x06,0x0E,0x2B,0x34,0x02,0x53,0x01,0x01,0x0D,0x01,0x01,0x01,0x01,0x01,0x42,0x00
> };
>
> +static const UID mxf_avc_subdescriptor_key = {
> 0x06,0x0E,0x2B,0x34,0x02,0x53,0x01,0x01,0x0d,0x01,0x01,0x01,0x01,0x01,0x6E,0x00
> };
> +
>  static int get_trc(UID ul, enum AVColorTransferCharacteristic trc)
>  {
>  switch (trc){
> @@ -1317,6 +1330,13 @@ static int64_t
> mxf_write_cdci_common(AVFormatContext *s, AVStream *st, const UID
>  avio_w8(pb, sc->field_dominance);
>  }
>
> +if (st->codecpar->codec_id == AV_CODEC_ID_H264 && !sc->avc_intra) {
> +// write avc sub descriptor 

Re: [FFmpeg-devel] [PATCH] avformat/mxfenc: support XAVC long gop

[Thomas Mundt]

Am Sa., 30. März 2019 um 17:52 Uhr schrieb Baptiste Coudurier <
baptiste.coudur...@gmail.com>:

> Hi Thomas,
>
> > On Mar 29, 2019, at 1:11 PM, Thomas Mundt  wrote:
> >
> >
> > […]
> >
> >>
> 0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x0a,0x04,0x01,0x02,0x02,0x01,0x32,0x31,0x04
> >> }, 568832, 122, 0,  1 }, // AVC High 422 Intra RP2027 Class 100 1080/25p
> >> +{{
> >>
> 0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x0a,0x04,0x01,0x02,0x02,0x01,0x32,0x31,0x08
> >> }, 236544, 122, 0,  1 }, // AVC High 422 Intra RP2027 Class 100
> 720/59.94p
> >> +{{
> >>
> 0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x0a,0x04,0x01,0x02,0x02,0x01,0x32,0x31,0x09
> >> }, 284672, 122, 0,  1 }, // AVC High 422 Intra RP2027 Class 100 720/50p
> >>
> >
> > Maybe i miss something, but doesn´t the setting of the profile for all
> AVC
> > Intra codec ULs make the for-loop to always select the last AVC Intra
> > codec UL (720/50p) for AVC High 422 Intra?
>
> The frame size check prevents that.
>

The frame size check in the first condition of the for-loop works for fixed
frame size RP2027. However, with free frame size AVC High 422 Intra, the
second condition in the for-loop only checks for profile and intra-only.
Since the second condition doesn´t break the for-loop, the last UL with
matching profile and intra-only flag is set.

I wanted to test this behavior, so I applied this patch to
cf81284b1c14ef28d3f94e6d28c46188ba4e82f2, which is the last one that can be
compiled.
Unfortunately I was not able to produce any h264 mxf with this patch.
E.g. the following command works perfect without this patch:
ffmpeg -f lavfi -i testsrc=size=3840x2160:rate=50 -c:v libx264 -pix_fmt
yuv422p10 -x264-params keyint=1 -t 1 avc.mxf
With this patch I get errors: h264 profile not supported, could not get
h264 profile.
Same with other formats or long gop.
RP2027 Class 100 1080/50i shows the following error: frame size does not
match index unit size, 568832 != 0

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

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

Re: [FFmpeg-devel] [PATCH] avformat/mxfenc: support XAVC long gop

[Thomas Mundt]

Am Do., 28. März 2019 um 16:51 Uhr schrieb Baptiste Coudurier <
baptiste.coudur...@gmail.com>:

> ---
>  libavformat/mxf.h|   1 +
>  libavformat/mxfenc.c | 194 ---
>  2 files changed, 145 insertions(+), 50 deletions(-)
>
> diff --git a/libavformat/mxf.h b/libavformat/mxf.h
> index 4394450dea..f32124f772 100644
> --- a/libavformat/mxf.h
> +++ b/libavformat/mxf.h
> @@ -48,6 +48,7 @@ enum MXFMetadataSetType {
>  EssenceGroup,
>  TaggedValue,
>  TapeDescriptor,
> +AVCSubDescriptor,
>  };
>
>  enum MXFFrameLayout {
> diff --git a/libavformat/mxfenc.c b/libavformat/mxfenc.c
> index 8c6db94865..b2e818a8a5 100644
> --- a/libavformat/mxfenc.c
> +++ b/libavformat/mxfenc.c
> @@ -49,7 +49,10 @@
>  #include "libavcodec/bytestream.h"
>  #include "libavcodec/dnxhddata.h"
>  #include "libavcodec/dv_profile.h"
> -#include "libavcodec/h264.h"
> +#include "libavcodec/golomb.h"
> +#include "libavcodec/h264data.h"
> +#include "libavcodec/h264_ps.h"
> +#include "libavcodec/h2645_parse.h"
>  #include "libavcodec/internal.h"
>  #include "audiointerleave.h"
>  #include "avformat.h"
> @@ -99,6 +102,7 @@ typedef struct MXFStreamContext {
>  int max_gop; ///< maximum gop size, used by mpeg-2
> descriptor
>  int b_picture_count; ///< maximum number of consecutive b
> pictures, used in mpeg-2 descriptor
>  int low_delay;   ///< low delay, used in mpeg-2 descriptor
> +int avc_intra;
>  } MXFStreamContext;
>
>  typedef struct MXFContainerEssenceEntry {
> @@ -167,6 +171,7 @@ static const struct {
>  static void mxf_write_wav_desc(AVFormatContext *s, AVStream *st);
>  static void mxf_write_aes3_desc(AVFormatContext *s, AVStream *st);
>  static void mxf_write_mpegvideo_desc(AVFormatContext *s, AVStream *st);
> +static void mxf_write_h264_desc(AVFormatContext *s, AVStream *st);
>  static void mxf_write_cdci_desc(AVFormatContext *s, AVStream *st);
>  static void mxf_write_generic_sound_desc(AVFormatContext *s, AVStream
> *st);
>  static void mxf_write_s436m_anc_desc(AVFormatContext *s, AVStream *st);
> @@ -310,7 +315,7 @@ static const MXFContainerEssenceEntry
> mxf_essence_container_uls[] = {
>  { {
> 0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x0a,0x0D,0x01,0x03,0x01,0x02,0x10,0x60,0x01
> },
>{
> 0x06,0x0E,0x2B,0x34,0x01,0x02,0x01,0x01,0x0D,0x01,0x03,0x01,0x15,0x01,0x05,0x00
> },
>{
> 0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x0a,0x04,0x01,0x02,0x02,0x01,0x00,0x00,0x00
> },
> -  mxf_write_mpegvideo_desc },
> +  mxf_write_h264_desc },
>  // S436M ANC
>  { {
> 0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x0a,0x0D,0x01,0x03,0x01,0x02,0x0e,0x00,0x00
> },
>{
> 0x06,0x0E,0x2B,0x34,0x01,0x02,0x01,0x01,0x0D,0x01,0x03,0x01,0x17,0x01,0x02,0x00
> },
> @@ -498,6 +503,12 @@ static const MXFLocalTagPair mxf_local_tag_batch[] = {
>  { 0x8006,
> {0x06,0x0E,0x2B,0x34,0x01,0x01,0x01,0x05,0x04,0x01,0x06,0x02,0x01,0x08,0x00,0x00}},
> /* MaxGOP */
>  { 0x8007,
> {0x06,0x0E,0x2B,0x34,0x01,0x01,0x01,0x05,0x04,0x01,0x06,0x02,0x01,0x0A,0x00,0x00}},
> /* ProfileAndLevel */
>  { 0x8008,
> {0x06,0x0E,0x2B,0x34,0x01,0x01,0x01,0x05,0x04,0x01,0x06,0x02,0x01,0x09,0x00,0x00}},
> /* BPictureCount */
> +// Generic Descriptor
> +{ 0x8100,
> {0x06,0x0E,0x2B,0x34,0x01,0x01,0x01,0x09,0x06,0x01,0x01,0x04,0x06,0x10,0x00,0x00}},
> /* SubDescriptors */
> +// AVC SubDescriptor
> +{ 0x8200,
> {0x06,0x0E,0x2B,0x34,0x01,0x01,0x01,0x0E,0x04,0x01,0x06,0x06,0x01,0x0E,0x00,0x00}},
> /* AVC Decoding Delay */
> +{ 0x8201,
> {0x06,0x0E,0x2B,0x34,0x01,0x01,0x01,0x0E,0x04,0x01,0x06,0x06,0x01,0x0A,0x00,0x00}},
> /* AVC Profile */
> +{ 0x8202,
> {0x06,0x0E,0x2B,0x34,0x01,0x01,0x01,0x0E,0x04,0x01,0x06,0x06,0x01,0x0D,0x00,0x00}},
> /* AVC Level */
>  // Wave Audio Essence Descriptor
>  { 0x3D09,
> {0x06,0x0E,0x2B,0x34,0x01,0x01,0x01,0x05,0x04,0x02,0x03,0x03,0x05,0x00,0x00,0x00}},
> /* Average Bytes Per Second */
>  { 0x3D0A,
> {0x06,0x0E,0x2B,0x34,0x01,0x01,0x01,0x05,0x04,0x02,0x03,0x02,0x01,0x00,0x00,0x00}},
> /* Block Align */
> @@ -1126,6 +1137,8 @@ static const UID mxf_aes3_descriptor_key  = {
> 0x06,0x0E,0x2B,0x34,0x02,0x53,
>  static const UID mxf_cdci_descriptor_key  = {
> 0x06,0x0E,0x2B,0x34,0x02,0x53,0x01,0x01,0x0D,0x01,0x01,0x01,0x01,0x01,0x28,0x00
> };
>  static const UID mxf_generic_sound_descriptor_key = {
> 0x06,0x0E,0x2B,0x34,0x02,0x53,0x01,0x01,0x0D,0x01,0x01,0x01,0x01,0x01,0x42,0x00
> };
>
> +static const UID mxf_avc_subdescriptor_key = {
> 0x06,0x0E,0x2B,0x34,0x02,0x53,0x01,0x01,0x0d,0x01,0x01,0x01,0x01,0x01,0x6E,0x00
> };
> +
>  static int get_trc(UID ul, enum AVColorTransferCharacteristic trc)
>  {
>  switch (trc){
> @@ -1317,6 +1330,13 @@ static int64_t
> mxf_write_cdci_common(AVFormatContext *s, AVStream *st, const UID
>  avio_w8(pb, sc->field_dominance);
>  }
>
> +if (st->codecpar->codec_id == AV_CODEC_ID_H264 && !sc->avc_intra) {
> +// write avc sub descriptor ref
> +

Re: [FFmpeg-devel] [PATCH 0/2] Update vf_bwdif to use yadif_common v2

[Thomas Mundt]

Am So., 11. Nov. 2018 um 20:47 Uhr schrieb Philip Langdale <
phil...@overt.org>:

> vf_bwdif's frame management logic is almost identical to that of yadif.
> The only difference is that it tracks the first and last fields in a
> sequence, and that requires slight changes to the common code.
>
> Assuming it's reasonable to do that tracking even though yadif doesn't
> need it, we can then remove all the duplicated logic.
>
> v2: Rename enum values as recommened by Thomas Mundt.
>
> Philip Langdale (2):
>   avfilter/yadif_common: Add field type tracking to help bwdif
>   avfilter/vf_bwdif: Use common yadif frame management logic
>
>  libavfilter/bwdif.h |  34 +
>  libavfilter/vf_bwdif.c  | 235 +---
>  libavfilter/x86/vf_bwdif_init.c |   3 +-
>  libavfilter/yadif.h |  14 ++
>  libavfilter/yadif_common.c  |  12 +-
>  5 files changed, 64 insertions(+), 234 deletions(-)
>

Patch lgtm.

Regards,
Thomas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/2] avfilter/yadif_common: Add field type tracking to help bwdif

[Thomas Mundt]

Am Sa., 10. Nov. 2018 um 18:47 Uhr schrieb Philip Langdale <
phil...@overt.org>:

> The bwdif filter can use common yadif frame management if we track
> when a field is the first or last field in a sequence. While this
> information is not used by yadif, the added benefit of removing the
> duplicated frame management logic makes it worth tracking this state
> in the common code.
> ---
>  libavfilter/yadif.h| 14 ++
>  libavfilter/yadif_common.c | 12 +---
>  2 files changed, 23 insertions(+), 3 deletions(-)
>
> diff --git a/libavfilter/yadif.h b/libavfilter/yadif.h
> index 32d6f4a0d4..02240a4dac 100644
> --- a/libavfilter/yadif.h
> +++ b/libavfilter/yadif.h
> @@ -41,6 +41,12 @@ enum YADIFDeint {
>  YADIF_DEINT_INTERLACED = 1, ///< only deinterlace frames marked as
> interlaced
>  };
>
> +enum YADIFCurrentField {
> +YADIF_FIELD_LAST   = -1, ///< The last field in a sequence
> +YADIF_FIELD_FIRST  =  0, ///< The first field in a sequence
> +YADIF_FIELD_NORMAL =  1, ///< A normal field in the middle of a
> sequence
> +};
>

These names are confusing for the bwdif code.
current_field == 0 means first or last field detected.
current_field == -1 means last frame detected.
Suggestion:
YADIF_FIELD_BACK_END = -1, ///   typedef struct YADIFContext {
>  const AVClass *class;
>
> @@ -70,6 +76,14 @@ typedef struct YADIFContext {
>  int eof;
>  uint8_t *temp_line;
>  int temp_line_size;
> +
> +/*
> + * An algorithm that treats first and/or last fields in a sequence
> + * differently can use this to detect those cases. It is the
> algorithm's
> + * responsibility to set the value to YADIF_FIELD_NORMAL after
> processing
> + * the first field.
> + */
> +int current_field;  ///< YADIFCurrentField
>  } YADIFContext;
>
>  void ff_yadif_init_x86(YADIFContext *yadif);
> diff --git a/libavfilter/yadif_common.c b/libavfilter/yadif_common.c
> index 19e8ac5281..213eca5396 100644
> --- a/libavfilter/yadif_common.c
> +++ b/libavfilter/yadif_common.c
> @@ -44,6 +44,8 @@ static int return_frame(AVFilterContext *ctx, int
> is_second)
>
>  av_frame_copy_props(yadif->out, yadif->cur);
>  yadif->out->interlaced_frame = 0;
> +if (yadif->current_field == YADIF_FIELD_LAST)
> +yadif->current_field = YADIF_FIELD_FIRST;
>  }
>
>  yadif->filter(ctx, yadif->out, tff ^ !is_second, tff);
> @@ -103,9 +105,12 @@ int ff_yadif_filter_frame(AVFilterLink *link, AVFrame
> *frame)
>  yadif->cur  = yadif->next;
>  yadif->next = frame;
>
> -if (!yadif->cur &&
> -!(yadif->cur = av_frame_clone(yadif->next)))
> -return AVERROR(ENOMEM);
> +if (!yadif->cur) {
> +yadif->cur = av_frame_clone(yadif->next);
> +if (!yadif->cur)
> +return AVERROR(ENOMEM);
> +yadif->current_field = YADIF_FIELD_FIRST;
> +}
>
>  if (checkstride(yadif, yadif->next, yadif->cur)) {
>  av_log(ctx, AV_LOG_VERBOSE, "Reallocating frame due to differing
> stride\n");
> @@ -173,6 +178,7 @@ int ff_yadif_request_frame(AVFilterLink *link)
>  if (!next)
>  return AVERROR(ENOMEM);
>
> +yadif->current_field = YADIF_FIELD_LAST;
>  next->pts = yadif->next->pts * 2 - yadif->cur->pts;
>
>  ff_yadif_filter_frame(ctx->inputs[0], next);
> --
> 2.19.1
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avfilter/vf_interlace: fix numerical options

[Thomas Mundt]

Am Do., 30. Aug. 2018 um 10:37 Uhr schrieb Thomas Mundt :

> Am Mo., 27. Aug. 2018 um 20:40 Uhr schrieb Thomas Mundt <
> tmund...@gmail.com>:
>
>> Am Mo., 27. Aug. 2018 um 19:40 Uhr schrieb Paul B Mahol > >:
>>
>>> On 8/27/18, Thomas Mundt  wrote:
>>> > Am Fr., 24. Aug. 2018 um 15:05 Uhr schrieb Paul B Mahol <
>>> one...@gmail.com>:
>>> >
>>> >> On 8/23/18, Thomas Mundt  wrote:
>>> >> > Currently numerical option values are misinterpreted in vf_interlace
>>> >> > filter.
>>> >> > Patch attached.
>>> >> >
>>> >> > Regards,
>>> >> > Thomas
>>> >> >
>>> >>
>>> >> ok
>>> >>
>>> >
>>> > Thanks. Can you please push it?
>>>
>>> Does this breaks tinterlace numerical options?
>>>
>>> Anyway numerical options are not supported, and is free to change.
>>>
>>
>> Indeed the numerical usage of the tinterlace option "flags" is changed.
>> But, as you say, numerical usage is not supported or even documented in
>> this case.
>> The "mode" option is unchanged and can be used numerical as documented.
>>
>
> Ping.
> Do you still have concerns?
>

Ping.
This patch fixes a regression and should be pushed.
Paul, please tell me if you need more time or information or if I should
ask someone else.

Regards,
Thomas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avfilter/vf_interlace: fix numerical options

[Thomas Mundt]

Am Mo., 27. Aug. 2018 um 20:40 Uhr schrieb Thomas Mundt :

> Am Mo., 27. Aug. 2018 um 19:40 Uhr schrieb Paul B Mahol  >:
>
>> On 8/27/18, Thomas Mundt  wrote:
>> > Am Fr., 24. Aug. 2018 um 15:05 Uhr schrieb Paul B Mahol <
>> one...@gmail.com>:
>> >
>> >> On 8/23/18, Thomas Mundt  wrote:
>> >> > Currently numerical option values are misinterpreted in vf_interlace
>> >> > filter.
>> >> > Patch attached.
>> >> >
>> >> > Regards,
>> >> > Thomas
>> >> >
>> >>
>> >> ok
>> >>
>> >
>> > Thanks. Can you please push it?
>>
>> Does this breaks tinterlace numerical options?
>>
>> Anyway numerical options are not supported, and is free to change.
>>
>
> Indeed the numerical usage of the tinterlace option "flags" is changed.
> But, as you say, numerical usage is not supported or even documented in
> this case.
> The "mode" option is unchanged and can be used numerical as documented.
>

Ping.
Do you still have concerns?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avfilter/vf_interlace: fix numerical options

[Thomas Mundt]

Am Mo., 27. Aug. 2018 um 19:40 Uhr schrieb Paul B Mahol :

> On 8/27/18, Thomas Mundt  wrote:
> > Am Fr., 24. Aug. 2018 um 15:05 Uhr schrieb Paul B Mahol <
> one...@gmail.com>:
> >
> >> On 8/23/18, Thomas Mundt  wrote:
> >> > Currently numerical option values are misinterpreted in vf_interlace
> >> > filter.
> >> > Patch attached.
> >> >
> >> > Regards,
> >> > Thomas
> >> >
> >>
> >> ok
> >>
> >
> > Thanks. Can you please push it?
>
> Does this breaks tinterlace numerical options?
>
> Anyway numerical options are not supported, and is free to change.
>

Indeed the numerical usage of the tinterlace option "flags" is changed.
But, as you say, numerical usage is not supported or even documented in
this case.
The "mode" option is unchanged and can be used numerical as documented.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avfilter/vf_interlace: fix numerical options

[Thomas Mundt]

Am Fr., 24. Aug. 2018 um 15:05 Uhr schrieb Paul B Mahol :

> On 8/23/18, Thomas Mundt  wrote:
> > Currently numerical option values are misinterpreted in vf_interlace
> > filter.
> > Patch attached.
> >
> > Regards,
> > Thomas
> >
>
> ok
>

Thanks. Can you please push it?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] avfilter/vf_interlace: fix numerical options

[Thomas Mundt]

Currently numerical option values are misinterpreted in vf_interlace filter.
Patch attached.

Regards,
Thomas


0001-avfilter-vf_interlace-fix-numerical-options.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 3/5] Renamed reinterlace to tinterlace

[Thomas Mundt]

Hi,

2018-08-16 13:56 GMT+02:00 Vasile Toncu :

> Hi,
>
> Thank you for the additional testing effort.
> Fixed the issue.
>
>
thanks, the patch looks good to me as far as I can judge.
It´s up to more experienced developers now to permit the license change.
Can anybody please have a look at this.

Regards,
Thomas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 3/5] Renamed reinterlace to tinterlace

[Thomas Mundt]

Hi,

2018-08-14 18:53 GMT+02:00 Vasile Toncu :

> Hi Thomas,
>
> I added the log messages.
>
> Thanks for the review.
>

I found some more time for testing this evening. Unfortunately there are
still issues.
I get half green pictures with some modes at high bit depth.
But the fix is easy.
The bytewidth in all av_image_copy_plane functions need to be adapted for
high bit depths.

{}
> const AVPixFmtDescriptor *fmt_desc = av_pix_fmt_desc_get(out->format);
> int mult = (fmt_desc->comp[0].depth > 8 ? 2 : 1);
>

You used the calculated "mult" in the av_image_copy_plane functions of
MODE_MERGE and MODE_PAD only.
And forgot the others:


> {}
>
+case MODE_INTERLEAVE_BOTTOM:
> +case MODE_INTERLEAVE_TOP:
> +y = y * 2;
> +
> +if (tinterlace->flags & FLAG_VLPF || tinterlace->flags &
> FLAG_CVLPF) {
> +int clip_max = (1 << fmt_desc->comp[plane].depth) - 1;
> +
> +interleave_filter_frame(tinterlace, first, out, plane,
> !!(tinterlace->flags & FLAG_CVLPF), tinterlace_mode == MODE_INTERLEAVE_TOP,
> x, y, clip_max);
> +interleave_filter_frame(tinterlace, second, out, plane,
> !!(tinterlace->flags & FLAG_CVLPF), tinterlace_mode ==
> MODE_INTERLEAVE_BOTTOM, x, y, clip_max);
>  } else {
> -if (tinterlace->csp->comp[plane].depth > 8)
> -cols *= 2;
> -av_image_copy_plane(dstp, dstp_linesize, srcp, srcp_linesize,
> cols, lines);
> +offset1 = (tinterlace_mode == MODE_INTERLEAVE_TOP) ? 0 :
> out->linesize[plane];
> +offset2 = (tinterlace_mode == MODE_INTERLEAVE_TOP) ? 0 :
> first->linesize[plane];
> +offset3 = (tinterlace_mode == MODE_INTERLEAVE_TOP) ?
> out->linesize[plane]: 0;
> +offset4 = (tinterlace_mode == MODE_INTERLEAVE_TOP) ?
> second->linesize[plane] : 0;
> +
> +av_image_copy_plane(out->data[plane] + offset1, 2 *
> out->linesize[plane],
> +first->data[plane] + offset2, 2 * first->linesize[plane],
> +first->width / x, first->height / y);
> +av_image_copy_plane(out->data[plane] + offset3, 2 *
> out->linesize[plane],
> +second->data[plane] + offset4, 2 *
> second->linesize[plane],
> +second->width / x, second->height / y);
>

Here

 }
> +break;
> +
> +case MODE_INTERLACE_X2:
> +y = y * 2;
> +
> +offset1 = 0; offset2 = 0;
> +offset3 = out->linesize[plane];
> +offset4 = second->linesize[plane];
> +
> +if (second->interlaced_frame && second->top_field_first) {
> +offset1 = out->linesize[plane];
> +offset2 = first->linesize[plane];
> +offset3 = 0; offset4 = 0;
> +}
> +
> +av_image_copy_plane(out->data[plane] + offset1, 2 *
> out->linesize[plane],
> +first->data[plane] + offset2, 2 * first->linesize[plane],
> +first->width / x, first->height / y);
> +av_image_copy_plane(out->data[plane] + offset3, 2 *
> out->linesize[plane],
> +second->data[plane] + offset4, 2 * second->linesize[plane],
> +second->width / x, second->height / y);
>

 Here

+break;
> +
> +case MODE_MERGE_X2:
> +if (IS_ODD(tinterlace->current_frame_index - 1)) {
> +av_image_copy_plane(out->data[plane], 2 *
> out->linesize[plane],
> +second->data[plane], second->linesize[plane],
> second->width / x, second->height / y);
> +av_image_copy_plane(out->data[plane] + out->linesize[plane],
> 2 * out->linesize[plane],
> +first->data[plane], first->linesize[plane], first->width
> / x, first->height / y);
> +} else {
> +av_image_copy_plane(out->data[plane], 2 *
> out->linesize[plane],
> +first->data[plane], first->linesize[plane], first->width
> / x, first->height / y);
> +av_image_copy_plane(out->data[plane] + out->linesize[plane],
> 2 * out->linesize[plane],
> +second->data[plane], second->linesize[plane],
> second->width / x, second->height / y);
>

Here.

Sorry for the piecemeal.

Regards,
Thomas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 3/5] Renamed reinterlace to tinterlace

[Thomas Mundt]

Hi,

2018-08-13 0:02 GMT+02:00 Vasile Toncu :

> Hello,
>
> I have updated patch 3 according to review, removed all code related to the
> new flags (MERGE_TFF, MERGE_BFF) and threading functionality.
>
>
Thanks, your patch looks fine to me now.
There is just one thing, I forgot to mention last review:


> {}
> -if (tinterlace->flags & (TINTERLACE_FLAG_VLPF | TINTERLACE_FLAG_CVLPF)
> -&& !(tinterlace->mode == MODE_INTERLEAVE_TOP
> -  || tinterlace->mode == MODE_INTERLEAVE_BOTTOM)) {
> -av_log(ctx, AV_LOG_WARNING, "low_pass_filter flags ignored with
> mode %d\n",
> -tinterlace->mode);
>
> {}
> +if (tinterlace->flags & FLAG_VLPF || tinterlace->flags & FLAG_CVLPF) {
>
> -av_log(ctx, AV_LOG_VERBOSE, "mode:%d filter:%s h:%d -> h:%d\n",
> tinterlace->mode,
> -   (tinterlace->flags & TINTERLACE_FLAG_CVLPF) ? "complex" :
> -   (tinterlace->flags & TINTERLACE_FLAG_VLPF) ? "linear" : "off",
> -   inlink->h, outlink->h);
>

Please keep the log messages. Nothing should change for the user.

Regards,
Thomas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 3/5] Renamed reinterlace to tinterlace

[Thomas Mundt]

Hi,

2018-07-24 12:17 GMT+02:00 Vasile Toncu :

> Fixed tabs.
> Thank you for the feedback.
>

> {}
> +case MODE_INTERLEAVE_BOTTOM:
> +case MODE_INTERLEAVE_TOP:
> +y = y * 2;
> +
> +if (tinterlace->flags & FLAG_VLPF || tinterlace->flags &
> FLAG_CVLPF) {
> +
> +int lines, cols, cvlfp;
> +AVFrame *from_frame;
> +uint8_t *from, *to;
> +int from_step, to_step;
> +
> +lines = (tinterlace_mode == MODE_INTERLEAVE_TOP) ? (2 *
> out->height / y + 1) / 2 : (2 * out->height / y + 0) / 2;
> +cols = out->width / x;
> +from_frame = first;
> +from = from_frame->data[plane];
> +to = out->data[plane];
> +
> +if (tinterlace_mode == MODE_INTERLEAVE_BOTTOM) {
> +from = from + from_frame->linesize[plane];
> +to = to + out->linesize[plane];
> +}
> +
> +from_step = 2 * from_frame->linesize[plane];
> +to_step = 2 * out->linesize[plane];
> +
> +// when i = lines - aka first line
> +tinterlace->lowpass_line(to, cols, from,
> from_frame->linesize[plane], 0, clip_max);
> +to += to_step;
> +from += from_step;
> +
> +cvlfp = !!(tinterlace->flags & FLAG_CVLPF);
> +if (cvlfp) {
> +tinterlace->lowpass_line(to, cols, from,
> from_frame->linesize[plane], 0, clip_max);
> +to += to_step;
> +from += from_step;
> +}
> +
> +for (i = lines - 2 - 2 * cvlfp; i; i--) {
> +tinterlace->lowpass_line(to, cols, from,
> from_frame->linesize[plane], -from_frame->linesize[plane], clip_max);
> +to += to_step;
> +from += from_step;
> +}
> +
> +// when i == 1 - aka last line
> +tinterlace->lowpass_line(to, cols, from, 0,
> -from_frame->linesize[plane], clip_max);
> +to += to_step;
> +from += from_step;
> +
> +if (cvlfp) {
> +tinterlace->lowpass_line(to, cols, from, 0,
> -from_frame->linesize[plane], clip_max);
> +to += to_step;
> +from += from_step;
> +}
> +
> +
> +lines = (tinterlace_mode == MODE_INTERLEAVE_BOTTOM) ? ((2 *
> out->height / y) + 1) / 2 : (2 * out->height / y + 0) / 2;
> +cols = out->width / x;
> +from_frame = second;
> +from = from_frame->data[plane];
> +to = out->data[plane];
> +
> +if (tinterlace_mode == MODE_INTERLEAVE_TOP) {
> +from = from + from_frame->linesize[plane];
> +to = to + out->linesize[plane];
>  }
> +
> +from_step = 2 * from_frame->linesize[plane];
> +to_step = 2 * out->linesize[plane];
> +
> +// when i = lines
> +tinterlace->lowpass_line(to, cols, from,
> from_frame->linesize[plane], 0, clip_max);
> +to += to_step;
> +from += from_step;
> +
> +if (cvlfp) {
> +tinterlace->lowpass_line(to, cols, from,
> from_frame->linesize[plane], 0, clip_max);
> +to += to_step;
> +from += from_step;
> +}
> +
> +
> +for (i = lines - 2 - 2 * cvlfp; i; i--) {
> +tinterlace->lowpass_line(to, cols, from,
> from_frame->linesize[plane], -from_frame->linesize[plane], clip_max);
> +to += to_step;
> +from += from_step;
> +}
> +
> +// when i == 1
> +tinterlace->lowpass_line(to, cols, from, 0,
> -from_frame->linesize[plane], clip_max);
> +to += to_step;
> +from += from_step;
> +
> +if (cvlfp) {
> +tinterlace->lowpass_line(to, cols, from, 0,
> -from_frame->linesize[plane], clip_max);
> +to += to_step;
> +from += from_step;
> +}
>

Compared to the one simple "for"-loop in the GPL version, this looks very
complicated. Maybe it´s ok here to just keep the original code since it has
been modified in the past anyway.
But at least you need to factor it out for not having the same code two
times in a row.

{}
> +case MODE_MERGE_TFF:
> +case MODE_MERGE_BFF:
> +offset1 = (tinterlace_mode == MODE_MERGE_TFF) ? 0 :
> out->linesize[plane];
> +offset2 = (tinterlace_mode == MODE_MERGE_TFF) ?
> out->linesize[plane] : 0;
> +
> +av_image_copy_plane(out->data[plane] + offset1, 2 *
> out->linesize[plane],
> +first->data[plane], first->linesize[plane], first->width / x,
> first->height / y);
> +av_image_copy_plane(out->data[plane] + offset2, 2 *
> out->linesize[plane],
> +second->data[plane], second->linesize[plane], second->width /
> x, second->height / y);
> +break;
>

These are new functions, independent from the license 

Re: [FFmpeg-devel] [PATCH 3/5] Renamed reinterlace to tinterlace

[Thomas Mundt]

2018-07-25 17:11 GMT+02:00 Vasile Toncu :

> What would be the next steps?
>
> On Tue, Jul 24, 2018 at 12:17 PM, Vasile Toncu 
> wrote:
>
> > Fixed tabs.
> > Thank you for the feedback.
> >
> > On Fri, Jul 20, 2018 at 7:27 PM, Paul B Mahol  wrote:
> >
> >> On 7/20/18, Vasile Toncu  wrote:
> >> > Hi,
> >> >
> >> > Did you have the time to take a look at patches 2 and 3? It's
> everything
> >> > fine?
> >>
> >> Yes and no, patches have tabs. Please fix that.
>

Please be patient. I´m just back from vacation and full of tasks at work.
You took months for the revised patches. Now I need to work into it first.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 3/5] Renamed reinterlace to tinterlace

[Thomas Mundt]

Hi,

2018-05-30 16:10 GMT+02:00 Vasile Toncu :

> Hello,
>
> I've sent a wrong version in the previous email for patch 3. Please
> ignore. This is the corect one.


the compiler warnings are gone, but fate-filter-pixfmts-tinterlace_pad
still fails.
Why do you replace the usage of draw utils for generating the black lines
in pad mode?
It´s not necessary for the relicensing since I implemented their usage in
vf_tintelace:
https://git.ffmpeg.org/gitweb/ffmpeg.git/commitdiff/58ca446672fec10e851b820ce7df64bd2d1f3a70

Regards,
Thomas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v3] avformat/mxfenc: add h264 profiles

[Thomas Mundt]

2018-05-07 10:40 GMT+02:00 Tomas Härdin <tjop...@acc.umu.se>:

> sön 2018-05-06 klockan 21:31 +0200 skrev Thomas Mundt:
> > 2018-05-06 13:32 GMT+02:00 Tomas Härdin <tjop...@acc.umu.se>:
> >
> > > fre 2018-05-04 klockan 01:52 +0200 skrev Thomas Mundt:
> > > > Hi,
> > > >
> > > > this is a better version of the patch.
> > > > 10 bit and TFF are mandatory for AVC Intra only. Other profiles
> > > > differ.
> > > >
> > > > diff --git a/libavformat/mxfenc.c b/libavformat/mxfenc.c
> > > > index 3bb7032..81513dc 100644
> > > > --- a/libavformat/mxfenc.c
> > > > +++ b/libavformat/mxfenc.c
> > > > @@ -1947,22 +1947,31 @@ static const struct {
> > > >  int frame_size;
> > > >  int profile;
> > > >  uint8_t interlaced;
> > > > +int long_gop;
> > >
> > > A comment here explaining the difference between -1, 0 and 1 would
> > > be
> > > nice. The rest looks OK, but I didn't read the relevant specs to be
> > > 100% sure
> > > <http://ffmpeg.org/mailman/listinfo/ffmpeg-devel>
> > >
> >
> > New patch attached.
>
> Looks OK


Thanks,

can you or someone else push it please.

Regards,
Thomas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v3] avformat/mxfenc: add h264 profiles

[Thomas Mundt]

2018-05-06 13:32 GMT+02:00 Tomas Härdin <tjop...@acc.umu.se>:

> fre 2018-05-04 klockan 01:52 +0200 skrev Thomas Mundt:
> > Hi,
> >
> > this is a better version of the patch.
> > 10 bit and TFF are mandatory for AVC Intra only. Other profiles
> > differ.
> >
>
> > diff --git a/libavformat/mxfenc.c b/libavformat/mxfenc.c
> > index 3bb7032..81513dc 100644
> > --- a/libavformat/mxfenc.c
> > +++ b/libavformat/mxfenc.c
> > @@ -1947,22 +1947,31 @@ static const struct {
> >  int frame_size;
> >  int profile;
> >  uint8_t interlaced;
> > +int long_gop;
>
> A comment here explaining the difference between -1, 0 and 1 would be
> nice. The rest looks OK, but I didn't read the relevant specs to be
> 100% sure
> <http://ffmpeg.org/mailman/listinfo/ffmpeg-devel>
>

New patch attached.

Regards,
Thomas


0001-avformat-mxfenc-add-h264-profiles.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v2] avformat/mxfenc: add h264 profiles

[Thomas Mundt]

Hi,

this is a better version of the patch.
10 bit and TFF are mandatory for AVC Intra only. Other profiles differ.

Regards,
Thomas


0001-avformat-mxfenc-add-h264-profiles.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avformat/mxfenc: add h264 profiles

[Thomas Mundt]

2018-04-30 19:27 GMT+02:00 Paul B Mahol <one...@gmail.com>:

> On 4/30/18, Thomas Mundt <tmund...@gmail.com> wrote:
> > Hi,
> >
> > attached patch adds some h264 profiles to the mxf encoder.
>
> *muxer, not encoder.
>

Right. I was writing mxfenc short before and seem to switched of my brain.

>
> > Please comment.
> >
> > Thomas
> >
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] avformat/mxfenc: add h264 profiles

[Thomas Mundt]

Hi,

attached patch adds some h264 profiles to the mxf encoder.
Please comment.

Thomas


0001-avformat-mxfenc-add-h264-profiles.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 3/5] Renamed reinterlace to tinterlace

[Thomas Mundt]

Hi,

2018-04-25 16:24 GMT+02:00 Vasile Toncu :

> Hello,
>
> Here is patch 3. I renamed reinterlace to tinterlace and replaced the
> functionality of tinterlace with the one from reinterlace. Please review.
>
> Thank you,
> Vasile
>

Same as I wrote for your previous version.
Lots of compiler warnings. Fate tests fail.
Please fix.

Regards,
Thomas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 3/5] reitnerlace - tinterlace-like filter under LGPL

[Thomas Mundt]

Hi,

2018-04-23 18:22 GMT+02:00 Vasile Toncu :

> Hello,
>
> Here is patch 3. Please review.
>
> Thank you,
> Vasile
>

Some fate tests fail when both patches are applied.
I also get lots of compiler warnings.
Please fix them and, as already said, run fate.
All tests must pass, otherwise there is something wrong with your filter.

Regards,
Thomas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/6] reitnerlace - tinterlace-like filter under LGPL

[Thomas Mundt]

Hi,

2018-04-17 13:33 GMT+02:00 Vasile Toncu <vasile.to...@tremend.com>:

>
>
> On 12.04.2018 19:45, Thomas Mundt wrote:
>
>>
>> You need to write separate AVOption interlace_options and AVFilter
>> avfilter_vf_interlace in vf_tinterlace.c
>> Have a look at this patch:
>> https://git.ffmpeg.org/gitweb/ffmpeg.git/commitdiff/88e0e205
>> 4d911b38662f681bdc267e08312d313a
>>
>> Regards,
>> Thomas
>> ___
>> ffmpeg-devel mailing list
>> ffmpeg-devel@ffmpeg.org
>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>>
> Hello,
>
> Here is the new patch in accordance with the one that you suggested as a
> model. Please review it and tell me when should I proceed with the next
> patch. The next patch will add vf_reinterlace.
>
> Thank you,
> Vasile
>
>
> From b72b643201187bf5d31d7bec9b5064d1b01c8179 Mon Sep 17 00:00:00 2001
> From: Vasile Toncu <vasile.to...@tremend.com>
> Date: Tue, 17 Apr 2018 13:48:28 +0300
> Subject: [PATCH] Removed vf_interlace.c
>
> ---
>  libavfilter/Makefile|   2 +-
>  libavfilter/vf_interlace.c  | 366 --
> --
>  libavfilter/vf_tinterlace.c |  26 
>  3 files changed, 27 insertions(+), 367 deletions(-)
>  delete mode 100644 libavfilter/vf_interlace.c
>
> diff --git a/libavfilter/Makefile b/libavfilter/Makefile
> index 3a9fb02..cfb0f1d 100644
> --- a/libavfilter/Makefile
> +++ b/libavfilter/Makefile
> @@ -231,7 +231,7 @@ OBJS-$(CONFIG_HYSTERESIS_FILTER) +=
> vf_hysteresis.o framesync.o
>  OBJS-$(CONFIG_IDET_FILTER)   += vf_idet.o
>  OBJS-$(CONFIG_IL_FILTER) += vf_il.o
>  OBJS-$(CONFIG_INFLATE_FILTER)+= vf_neighbor.o
> -OBJS-$(CONFIG_INTERLACE_FILTER)  += vf_interlace.o
> +OBJS-$(CONFIG_INTERLACE_FILTER)  += vf_tinterlace.o
>  OBJS-$(CONFIG_INTERLEAVE_FILTER) += f_interleave.o
>  OBJS-$(CONFIG_KERNDEINT_FILTER)  += vf_kerndeint.o
>  OBJS-$(CONFIG_LENSCORRECTION_FILTER) += vf_lenscorrection.o
> diff --git a/libavfilter/vf_interlace.c b/libavfilter/vf_interlace.c
> deleted file mode 100644
> index 24c422d..000
> --- a/libavfilter/vf_interlace.c
> +++ /dev/null
> @@ -1,366 +0,0 @@
> -/*
> - * Copyright (c) 2003 Michael Zucchi <not...@ximian.com>
> - * Copyright (c) 2010 Baptiste Coudurier
> - * Copyright (c) 2011 Stefano Sabatini
> - * Copyright (c) 2013 Vittorio Giovara <vittorio.giov...@gmail.com>
> - * Copyright (c) 2017 Thomas Mundt <tmund...@gmail.com>
> - *
> - * This file is part of FFmpeg.
> - *
> - * FFmpeg is free software; you can redistribute it and/or modify
> - * it under the terms of the GNU General Public License as published by
> - * the Free Software Foundation; either version 2 of the License, or
> - * (at your option) any later version.
> - *
> - * FFmpeg is distributed in the hope that it will be useful,
> - * but WITHOUT ANY WARRANTY; without even the implied warranty of
> - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> - * GNU General Public License for more details.
> - *
> - * You should have received a copy of the GNU General Public License along
> - * with FFmpeg; if not, write to the Free Software Foundation, Inc.,
> - * 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
> - */
> -
> -/**
> - * @file
> - * progressive to interlaced content filter, inspired by heavy debugging
> of tinterlace filter
> - */
> -
> -#include "libavutil/common.h"
> -#include "libavutil/opt.h"
> -#include "libavutil/imgutils.h"
> -#include "libavutil/avassert.h"
> -
> -#include "formats.h"
> -#include "avfilter.h"
> -#include "interlace.h"
> -#include "internal.h"
> -#include "video.h"
> -
> -#define OFFSET(x) offsetof(InterlaceContext, x)
> -#define FLAGS AV_OPT_FLAG_FILTERING_PARAM|AV_OPT_FLAG_VIDEO_PARAM
> -static const AVOption interlace_options[] = {
> -{ "scan", "scanning mode", OFFSET(scan),
> -AV_OPT_TYPE_INT,   {.i64 = MODE_TFF }, 0, 1, .flags = FLAGS,
> .unit = "scan" },
> -{ "tff", "top field first", 0,
> -AV_OPT_TYPE_CONST, {.i64 = MODE_TFF }, INT_MIN, INT_MAX, .flags =
> FLAGS, .unit = "scan" },
> -{ "bff", "bottom field first", 0,
> -AV_OPT_TYPE_CONST, {.i64 = MODE_BFF }, INT_MIN, INT_MAX, .flags =
> FLAGS, .unit = "scan" },
> -{ "lowpass", "set vertical low-pass filter", OFFSET

Re: [FFmpeg-devel] [PATCH 1/6] reitnerlace - tinterlace-like filter under LGPL

[Thomas Mundt]

Hi,

2018-04-10 22:34 GMT+02:00 Vasile Toncu :

> Hello,
>
> This is the first part of the first patch. I added interlace options to
> tinterlace. On the next patch I will delete vf_interlace.
>
>
> Thank you,
>
> Vasile Toncu
>
>
> From b2be4e949e071f9017d8a9d6fbd1fbb56505ac50 Mon Sep 17 00:00:00 2001
> From: Vasile Toncu 
> Date: Tue, 10 Apr 2018 23:28:32 +0300
> Subject: [PATCH] Added interlace options to tinterlace
>
> ---
>  libavfilter/Makefile| 2 +-
>  libavfilter/vf_tinterlace.c | 9 +
>  2 files changed, 10 insertions(+), 1 deletion(-)
>
> diff --git a/libavfilter/Makefile b/libavfilter/Makefile
> index a90ca30..586d9c7 100644
> --- a/libavfilter/Makefile
> +++ b/libavfilter/Makefile
> @@ -231,7 +231,7 @@ OBJS-$(CONFIG_HYSTERESIS_FILTER) += vf_hysteresis.o
> framesync.o
>  OBJS-$(CONFIG_IDET_FILTER)   += vf_idet.o
>  OBJS-$(CONFIG_IL_FILTER) += vf_il.o
>  OBJS-$(CONFIG_INFLATE_FILTER)+= vf_neighbor.o
> -OBJS-$(CONFIG_INTERLACE_FILTER)  += vf_interlace.o
> +OBJS-$(CONFIG_INTERLACE_FILTER)  += vf_tinterlace.o
>  OBJS-$(CONFIG_INTERLEAVE_FILTER) += f_interleave.o
>  OBJS-$(CONFIG_KERNDEINT_FILTER)  += vf_kerndeint.o
>  OBJS-$(CONFIG_LENSCORRECTION_FILTER) += vf_lenscorrection.o
> diff --git a/libavfilter/vf_tinterlace.c b/libavfilter/vf_tinterlace.c
> index f13791d..5bf384d 100644
> --- a/libavfilter/vf_tinterlace.c
> +++ b/libavfilter/vf_tinterlace.c
> @@ -53,6 +53,15 @@ static const AVOption tinterlace_options[] = {
>  {"complex_filter","enable complex vertical low-pass filter",
> 0, AV_OPT_TYPE_CONST, {.i64 = TINTERLACE_FLAG_CVLPF},INT_MIN, INT_MAX,
> FLAGS, "flags" },
>  {"cvlpf", "enable complex vertical low-pass filter",
> 0, AV_OPT_TYPE_CONST, {.i64 = TINTERLACE_FLAG_CVLPF},INT_MIN, INT_MAX,
> FLAGS, "flags" },
>  {"exact_tb",  "force a timebase which can represent
> timestamps exactly", 0, AV_OPT_TYPE_CONST, {.i64 =
> TINTERLACE_FLAG_EXACT_TB}, INT_MIN, INT_MAX, FLAGS, "flags" },
> +
> +{"scan",  "scanning mode",
> 0, AV_OPT_TYPE_CONST, {.i64 = MODE_INTERLEAVE_TOP},INT_MIN, INT_MAX,
> FLAGS, "mode"},
> +{"tff",   "top field first",
> 0, AV_OPT_TYPE_CONST, {.i64 = MODE_INTERLEAVE_TOP},INT_MIN, INT_MAX,
> FLAGS, "mode"},
> +{"bff",   "bottom field first",
> 0, AV_OPT_TYPE_CONST, {.i64 = MODE_INTERLEAVE_BOTTOM}, INT_MIN, INT_MAX,
> FLAGS, "mode"},
> +
> +{"lowpass",   "set vertical low-pass filter",
> 0, AV_OPT_TYPE_CONST, {.i64 = TINTERLACE_FLAG_VLPF}, INT_MIN, INT_MAX,
> FLAGS, "flags"},
> +{"off",   "disable low-pass filter",
> 0, AV_OPT_TYPE_CONST, {.i64 = 0},INT_MIN, INT_MAX,
> FLAGS, "flags" },
> +{"linear","linear vertical low-pass filter",
> 0, AV_OPT_TYPE_CONST, {.i64 = TINTERLACE_FLAG_VLPF}, INT_MIN, INT_MAX,
> FLAGS, "flags" },
> +{"complex",   "complex vertical low-pass filter",
> 0, AV_OPT_TYPE_CONST, {.i64 = TINTERLACE_FLAG_CVLPF},INT_MIN, INT_MAX,
> FLAGS, "flags" },
>
>  {NULL}
>  };
> --
>
>
You need to write separate AVOption interlace_options and AVFilter
avfilter_vf_interlace in vf_tinterlace.c
Have a look at this patch:
https://git.ffmpeg.org/gitweb/ffmpeg.git/commitdiff/88e0e2054d911b38662f681bdc267e08312d313a

Regards,
Thomas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] reitnerlace - tinterlace-like filter under LGPL

[Thomas Mundt]

2018-03-29 15:44 GMT+02:00 Vasile Toncu <vasile.to...@tremend.com>:

>
>
> On 14.03.2018 18:56, Thomas Mundt wrote:
>
>> 2018-03-13 16:10 GMT+01:00 Vasile Toncu <vasile.to...@tremend.com>:
>>
>>
>>> On 06.03.2018 20:38, Thomas Mundt wrote:
>>>
>>> Hi,
>>>>
>>>> 2018-03-05 13:48 GMT+01:00 Carl Eugen Hoyos <ceffm...@gmail.com>:
>>>>
>>>> 2018-03-05 12:37 GMT+01:00, Paul B Mahol <one...@gmail.com>:
>>>>
>>>>> On 3/5/18, Vasile Toncu <vasile.to...@tremend.com> wrote:
>>>>>>
>>>>>> Hello,
>>>>>>>
>>>>>>> Thanks for the review. I've made changes according to your guidance.
>>>>>>>
>>>>>>> It would be great to know if the community will go on with our
>>>>>>> intention
>>>>>>> of adding reinterlace as a alternative for tinterlace.
>>>>>>>
>>>>>>> That being said, here is the new patch.
>>>>>>>
>>>>>>> As already said, this is not acceptable.
>>>>>>
>>>>>> There is no point in having 2 filters with near same funcionality.
>>>>>>
>>>>>> If you consider the new filter ok, the existing filter will be removed
>>>>> in the same push. I believe sending only the new filter makes
>>>>> reviewing easier.
>>>>>
>>>>> For me reviewing would be easier when Vasile sends a patchset that
>>>>>
>>>> includes
>>>> the replacement of tinterlace filter.
>>>> That way existing fate tests could be used which are fortunately pretty
>>>> extensive in this case.
>>>> Also it would be helpful when you and/or other experienced ffmpeg
>>>> developers would clarify first which parts of tinterlace have to be
>>>> rewritten for proper relicensing.
>>>> Being left in the dark makes working on patches frustrating.
>>>>
>>>> Another question is how to deal with vf_interlace? IMHO for the user
>>>> there
>>>> should be no difference in output, speed and license.
>>>> Two options:
>>>> 1. Relicensing and slice threading will also be ported to vf_interlace
>>>> 2. The commands from vf_interlace will be included in the new tinterlace
>>>> filter. vf_interlace will be deleted together with old tinterlace filter
>>>>
>>>> I would prefer the second option, but maybe there are even better
>>>> options
>>>> that don´t come to my mind.
>>>>
>>>> Please comment.
>>>> Thanks,
>>>> Thomas
>>>> ___
>>>> ffmpeg-devel mailing list
>>>> ffmpeg-devel@ffmpeg.org
>>>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>>>>
>>>> Hello everyone,
>>>
>>> sorry for a delayed response.
>>>
>>>  From what has been discussed in here, I think the reinterlace will exist
>>> with tinterlace for a period of time, just after that the tinterlace can
>>> be
>>> removed.
>>>
>>> To have the reinterlace added, what is needed to be done from my side?
>>>
>>> Thanks,
>>> Vasile Toncu
>>>
>>> Two filters with almost the same functionality won´t be accepted, as Paul
>> stated in this thread.
>> Also there is vf_interlace filter, which is a subset of vf_tinterlace and
>> should not differ in speed, output and license. As already said, I would
>> prefer to include vf_interlace options into vf_tinterlace and remove
>> vf_interlace.
>> Also you want several changes: Making tinterlace filter LGPL, adding new
>> options and adding slice threading.
>> This should be done in a patch set:
>>
>> Patch 1/5: Include vf_interlace options into vf_tinterlace filter and
>> remove vf_interlace
>>
>
> Hello,
>
> Further research I've made showed that vf_tinterlace already contains all
> the functionality from vf_interlace. I am ready to start the patches.
>
> Please confirm.
>

The functionality is not the point. The options must not be removed.
"ffmpeg -i input vf interlace output" must remain for the user.


> Regards,
> Vasile Toncu
>
>> Patch 2/5: Your new LGPL vf_reinterlace filter without the new options,
>> fixes and slice threading
>> Patch 3/5: Rename vf_reinterlace and replace vf_tinterlace by it
>> Patch 4/5: Add slice threading
>> Patch 5/5: Add the new options and fate tests for them
>>
>> Please run fate. All tests should pass.
>> As already said, I don´t have the skills to suggest what has to be done
>> making the relicensing legal. So I can do a technical review only.
>> These are just my suggestions to the best of my knowledge! There might be
>> better ideas from more experienced developers.
>> Please comment.
>>
>> Regards,
>> Thomas
>> ___
>> ffmpeg-devel mailing list
>> ffmpeg-devel@ffmpeg.org
>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>>
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] reitnerlace - tinterlace-like filter under LGPL

[Thomas Mundt]

2018-03-13 16:10 GMT+01:00 Vasile Toncu <vasile.to...@tremend.com>:

>
>
> On 06.03.2018 20:38, Thomas Mundt wrote:
>
>> Hi,
>>
>> 2018-03-05 13:48 GMT+01:00 Carl Eugen Hoyos <ceffm...@gmail.com>:
>>
>> 2018-03-05 12:37 GMT+01:00, Paul B Mahol <one...@gmail.com>:
>>>
>>>> On 3/5/18, Vasile Toncu <vasile.to...@tremend.com> wrote:
>>>>
>>>>> Hello,
>>>>>
>>>>> Thanks for the review. I've made changes according to your guidance.
>>>>>
>>>>> It would be great to know if the community will go on with our
>>>>> intention
>>>>> of adding reinterlace as a alternative for tinterlace.
>>>>>
>>>>> That being said, here is the new patch.
>>>>>
>>>> As already said, this is not acceptable.
>>>>
>>>> There is no point in having 2 filters with near same funcionality.
>>>>
>>> If you consider the new filter ok, the existing filter will be removed
>>> in the same push. I believe sending only the new filter makes
>>> reviewing easier.
>>>
>>> For me reviewing would be easier when Vasile sends a patchset that
>> includes
>> the replacement of tinterlace filter.
>> That way existing fate tests could be used which are fortunately pretty
>> extensive in this case.
>> Also it would be helpful when you and/or other experienced ffmpeg
>> developers would clarify first which parts of tinterlace have to be
>> rewritten for proper relicensing.
>> Being left in the dark makes working on patches frustrating.
>>
>> Another question is how to deal with vf_interlace? IMHO for the user there
>> should be no difference in output, speed and license.
>> Two options:
>> 1. Relicensing and slice threading will also be ported to vf_interlace
>> 2. The commands from vf_interlace will be included in the new tinterlace
>> filter. vf_interlace will be deleted together with old tinterlace filter
>>
>> I would prefer the second option, but maybe there are even better options
>> that don´t come to my mind.
>>
>> Please comment.
>> Thanks,
>> Thomas
>> ___
>> ffmpeg-devel mailing list
>> ffmpeg-devel@ffmpeg.org
>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>>
>
> Hello everyone,
>
> sorry for a delayed response.
>
> From what has been discussed in here, I think the reinterlace will exist
> with tinterlace for a period of time, just after that the tinterlace can be
> removed.
>
> To have the reinterlace added, what is needed to be done from my side?
>
> Thanks,
> Vasile Toncu
>

Two filters with almost the same functionality won´t be accepted, as Paul
stated in this thread.
Also there is vf_interlace filter, which is a subset of vf_tinterlace and
should not differ in speed, output and license. As already said, I would
prefer to include vf_interlace options into vf_tinterlace and remove
vf_interlace.
Also you want several changes: Making tinterlace filter LGPL, adding new
options and adding slice threading.
This should be done in a patch set:

Patch 1/5: Include vf_interlace options into vf_tinterlace filter and
remove vf_interlace
Patch 2/5: Your new LGPL vf_reinterlace filter without the new options,
fixes and slice threading
Patch 3/5: Rename vf_reinterlace and replace vf_tinterlace by it
Patch 4/5: Add slice threading
Patch 5/5: Add the new options and fate tests for them

Please run fate. All tests should pass.
As already said, I don´t have the skills to suggest what has to be done
making the relicensing legal. So I can do a technical review only.
These are just my suggestions to the best of my knowledge! There might be
better ideas from more experienced developers.
Please comment.

Regards,
Thomas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] reitnerlace - tinterlace-like filter under LGPL

[Thomas Mundt]

2018-03-07 0:49 GMT+01:00 Carl Eugen Hoyos <ceffm...@gmail.com>:

> 2018-03-06 19:38 GMT+01:00, Thomas Mundt <tmund...@gmail.com>:
> >
> > 2018-03-05 13:48 GMT+01:00 Carl Eugen Hoyos <ceffm...@gmail.com>:
> >
> >> 2018-03-05 12:37 GMT+01:00, Paul B Mahol <one...@gmail.com>:
> >> > On 3/5/18, Vasile Toncu <vasile.to...@tremend.com> wrote:
> >> >> Hello,
> >> >>
> >> >> Thanks for the review. I've made changes according to your guidance.
> >> >>
> >> >> It would be great to know if the community will go on with our
> >> >> intention
> >> >> of adding reinterlace as a alternative for tinterlace.
> >> >>
> >> >> That being said, here is the new patch.
> >> >
> >> > As already said, this is not acceptable.
> >> >
> >> > There is no point in having 2 filters with near same funcionality.
> >>
> >> If you consider the new filter ok, the existing filter will be removed
> >> in the same push. I believe sending only the new filter makes
> >> reviewing easier.
> >
> > For me reviewing would be easier when Vasile sends a patchset
> > that includes the replacement of tinterlace filter.
>
> The first patch would be quite trivial, this patch is the one you have to
> review...
>
> > That way existing fate tests could be used which are fortunately pretty
> > extensive in this case.
>
> I thought that one patch should remove the existing filter and
> another one adding the new one but I agree that fate suggests
> to do this in one patch.
>

I would have no problem using fate with two patches - one that removes
vf_tinterlace and another that adds a new vf_tinterlace when they are both
available for the review.
But it seems that Vasile, and to be honest me too, understood your
suggestion that first he shall send a new filter with a different name.
That one shall be reviewed and later on vf_ tinterlace be replaced.

> Also it would be helpful when you and/or other experienced ffmpeg
> > developers would clarify first which parts of tinterlace have to be
> > rewritten for proper relicensing.
>
> The suggestion is to replace the whole filter instead of rewriting
> parts which definitely is the safer solution.
>

Do you mean the whole filter shall be rewritten?
I´m sorry, but I have no clue at what difference from the original, code,
that does the same thing, can be considered as rewritten.


>
> > Being left in the dark makes working on patches frustrating.
>
> I don't understand this comment, sorry.
>

I hope my answer above explains my problem.


>
> > Another question is how to deal with vf_interlace? IMHO for the user
> there
> > should be no difference in output, speed and license.
>
> The whole point of this patch is to make a difference license-wise:
> Having the same filter also for default compilation is an improvement
> imo.
>
> > Two options:
> > 1. Relicensing and slice threading will also be ported to vf_interlace
>
> > 2. The commands from vf_interlace will be included in the new tinterlace
> > filter. vf_interlace will be deleted together with old tinterlace filter
>
> I believe 2 was suggested. Is the patch not sufficient?
>

I didn´t notice that anything was suggested in relation to vf_interlace.
It is not included in the patch and maybe should be separate one.


> > I would prefer the second option, but maybe there are even better options
> > that don´t come to my mind.
>
>
Regards,
Thomas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] reitnerlace - tinterlace-like filter under LGPL

[Thomas Mundt]

Hi,

2018-03-05 13:48 GMT+01:00 Carl Eugen Hoyos :

> 2018-03-05 12:37 GMT+01:00, Paul B Mahol :
> > On 3/5/18, Vasile Toncu  wrote:
> >> Hello,
> >>
> >> Thanks for the review. I've made changes according to your guidance.
> >>
> >> It would be great to know if the community will go on with our intention
> >> of adding reinterlace as a alternative for tinterlace.
> >>
> >> That being said, here is the new patch.
> >
> > As already said, this is not acceptable.
> >
> > There is no point in having 2 filters with near same funcionality.
>
> If you consider the new filter ok, the existing filter will be removed
> in the same push. I believe sending only the new filter makes
> reviewing easier.
>

For me reviewing would be easier when Vasile sends a patchset that includes
the replacement of tinterlace filter.
That way existing fate tests could be used which are fortunately pretty
extensive in this case.
Also it would be helpful when you and/or other experienced ffmpeg
developers would clarify first which parts of tinterlace have to be
rewritten for proper relicensing.
Being left in the dark makes working on patches frustrating.

Another question is how to deal with vf_interlace? IMHO for the user there
should be no difference in output, speed and license.
Two options:
1. Relicensing and slice threading will also be ported to vf_interlace
2. The commands from vf_interlace will be included in the new tinterlace
filter. vf_interlace will be deleted together with old tinterlace filter

I would prefer the second option, but maybe there are even better options
that don´t come to my mind.

Please comment.
Thanks,
Thomas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] reitnerlace - tinterlace-like filter under LGPL

[Thomas Mundt]

Hi,

2018-02-12 16:37 GMT+01:00 Vasile Toncu <vasile.to...@tremend.com>:

> Hello,
>
> there have been some discussions about tinterlace filter licensing. In the
> end, I was unable to contact all the authorship holders.
>
> The main author, one from MPlayer project, is Michael Zucchi. It is quite
> probably that the copyright is holden by the company that he worked for,
> Ximian, which no longer exists. It is less probably that I'll came up with
> the approval off all the parts involved in this deal.
>
> However, some of the later developers of tinterlace agreed to release the
> parts they wrote under LGPL. I mention here Thomas Mundt and Stefano
> Sabatini.
>
> This being said, I come up with a new filter - reinterlace - which
> implements all the tinterlace functionalities and adds a few more.
>
> The new filter is added to ffmpeg without --enable-gpl and/or
> --enable-nonfree. However, it these configure options are specified, the
> reinterlace will use ASM opts, imported from tinterlace. I've used support
> for 16bit depth video from the code written by Thomas Mundt. I added 2 new
> modes MERGE_BFF and MERGE_TFF. I've changed MODE_PAD, so it does not drop
> last frame from the input - tinterlace did so.
>
> In terms of performance, reinterlace gives basically the same fps as
> tinterlace does.
>
> Here is the patch thats adds the filter. If everything goes well with this
> patch, I'll add a new patch that changes current tinterlace with
> reinterlace.
>

since I´m maintainer of the tinterlace filter I should review your patch.
Unfortunately I don´t have a possibility to compile or test it ATM.
So the review is incomplete and following comments are only parts of the
changes that might be necessary.
Also I don´t know which requirements have to be fulfilled for porting code
from GPL to LGPL.
I will need help from more experienced ffmpeg developers.


> Thanks,
>
> -Vasile Toncu
>
> From 45010f4b4671edfe1318b84285d09dd28a882d63 Mon Sep 17 00:00:00 2001
> From: Vasile Toncu <vasile.to...@tremend.com>
> Date: Mon, 12 Feb 2018 14:16:27 +0200
> Subject: [PATCH] Added reitnerlace filter.
>
> ---
>  libavfilter/Makefile  |   1 +
>  libavfilter/allfilters.c  |   1 +
>  libavfilter/reinterlace.h | 141 +++
>  libavfilter/vf_reinterlace.c  | 773
> ++
>  libavfilter/x86/Makefile  |   1 +
>  libavfilter/x86/vf_reinterlace_init.c | 101 +
>  6 files changed, 1018 insertions(+)
>  create mode 100644 libavfilter/reinterlace.h
>  create mode 100644 libavfilter/vf_reinterlace.c
>  create mode 100644 libavfilter/x86/vf_reinterlace_init.c
>
> diff --git a/libavfilter/Makefile b/libavfilter/Makefile
> index 6a60836..c3095ba 100644
> --- a/libavfilter/Makefile
> +++ b/libavfilter/Makefile
> @@ -286,6 +286,7 @@ OBJS-$(CONFIG_RANDOM_FILTER) += vf_random.o
>  OBJS-$(CONFIG_READEIA608_FILTER) += vf_readeia608.o
>  OBJS-$(CONFIG_READVITC_FILTER)   += vf_readvitc.o
>  OBJS-$(CONFIG_REALTIME_FILTER)   += f_realtime.o
> +OBJS-$(CONFIG_REINTERLACE_FILTER)+= vf_reinterlace.o
>  OBJS-$(CONFIG_REMAP_FILTER)  += vf_remap.o framesync.o
>  OBJS-$(CONFIG_REMOVEGRAIN_FILTER)+= vf_removegrain.o
>  OBJS-$(CONFIG_REMOVELOGO_FILTER) += bbox.o lswsutils.o
> lavfutils.o vf_removelogo.o
> diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c
> index 9adb109..60fb9b5 100644
> --- a/libavfilter/allfilters.c
> +++ b/libavfilter/allfilters.c
> @@ -295,6 +295,7 @@ static void register_all(void)
>  REGISTER_FILTER(READEIA608, readeia608, vf);
>  REGISTER_FILTER(READVITC,   readvitc,   vf);
>  REGISTER_FILTER(REALTIME,   realtime,   vf);
> +REGISTER_FILTER(REINTERLACE,reinterlace,vf);
>  REGISTER_FILTER(REMAP,  remap,  vf);
>  REGISTER_FILTER(REMOVEGRAIN,removegrain,vf);
>  REGISTER_FILTER(REMOVELOGO, removelogo, vf);
> diff --git a/libavfilter/reinterlace.h b/libavfilter/reinterlace.h
> new file mode 100644
> index 000..bb66f63
> --- /dev/null
> +++ b/libavfilter/reinterlace.h
> @@ -0,0 +1,141 @@
> +/*
> + * Copyright (c) 2017 Vasile Toncu <toncu.vas...@gmail.com>
> + Copyright (c) 2017 Thomas Mundt <tmund...@gmail.com>
> + *
> + * This file is part of FFmpeg.
> + *
> + * FFmpeg is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU Lesser General Public
> + * License as published by the Free Software Foundation; either
> + * version 2.1 of the License, or (at your option) any later version.
> + *
> + * FFmpeg is distrib

Re: [FFmpeg-devel] tinterlace license

[Thomas Mundt]

Hi,

2018-02-05 11:58 GMT+01:00 Vasile Toncu <vasile.to...@tremend.com>:

> Hello,
>
> I'm looking forward to modify *tinterlace* filter from GPL to LGPL. The
> ASM opts will remain under GPL.
>
> Previously I tried to make a whole new filter, *reinterlace*, that acts
> just like tinterlace, but it happens that this task results in unnecessary
> duplicated code.
>
> I want to address the main copyright holders Thomas Mundt, Stefano
> Sabatini, Baptiste Coudurier and other ffmpeg maintainers for their
> approval.
>

I have no objections changing the license to LGPL, but can only determine
for the parts I authored.
That´s the complex vertical low pass filter and support for high bitdepths.

Regards,
Thomas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] avfilter/vf_interlace : add checkasm for lowpass_line and AVX2 version

[Thomas Mundt]

2017-12-19 22:57 GMT+01:00 James Almer :

> On 12/19/2017 6:40 PM, Martin Vignali wrote:
> > 2017-12-19 21:59 GMT+01:00 James Almer :
> >
> >> On 12/19/2017 5:16 PM, Martin Vignali wrote:
> 
>  LGTM, thanks.
> 
> >>>
> >>> Pushed, thanks
> >>
> >> This broke several interlace fate tests, including the new checkasm one
> >> you added.
> >>
> >> Sorry forget to run fate after AVX2 patch (only test with checkasm)
> >
> > For the checkasm fail, i can't reproduce it (on x86_64)
>
> I can reproduce it on mingw (x86_64), but not on Linux 86_64.
>

Sorry, I also should have run fate before saying LGTM.
Can´t reproduce the checkasm fail on msys2 x86_32. Only got this machine
atm.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] avfilter/vf_interlace : add checkasm for lowpass_line and AVX2 version

[Thomas Mundt]

2017-12-18 11:34 GMT+01:00 Martin Vignali :

> > >
> >
> > Please also add the changes you made in patch 1 and avx2 to
> vf_tinterlace.
> >
> >
> >
> > For patch 1, IMHO, it's not necessary (the modification is mainly to make
> checkasm test easier to write, and like vf_interlace and vf_tinterlace use
> the same asm
> only one is useful for checkasm)
>

I just thought it might be easier to maintain when code in both filters is
more similar.
But it´s not a big thing, so OK.

In attach new patchs, adding AVX2 lowpass_line 8 and 16 for vf_tinterlace
>

LGTM, thanks.
Do you think, that the complex low pass filter could also be improved that
way?

Regards,
Thomas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] avfilter/vf_interlace and vf_tinterlace : remove avx version

[Thomas Mundt]

Hi,

2017-12-16 18:38 GMT+01:00 Martin Vignali :

> Hello,
>
> Following discussion "avfilter/vf_interlace : add checkasm for lowpass_line
> and AVX2 version"
> the AVX version seems to be slower than SSE
>
> Patch in attach remove it, for vf_interlace and vf_tinterlace (both use the
> same SIMD)
>

when running checkasm several times sse2 is mostly faster here, not always.
But the difference is quite small.
Since I´m not an SIMD expert I´m fine with this patch as long as no one
with more expertise objects.

Regards,
Thomas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] avfilter/vf_interlace : add checkasm for lowpass_line and AVX2 version

[Thomas Mundt]

Hi,

2017-12-16 18:35 GMT+01:00 Martin Vignali :

> 2017-12-16 14:48 GMT+01:00 Carl Eugen Hoyos :
>
> > 2017-12-16 14:17 GMT+01:00 Martin Vignali :
> >
> > > 002 : Checkasm test for lowpass_line
> >
> > The change to checkasm.mak contains unexpected tabs iiuc.
> >
>
> New patch in attach
>

Please also add the changes you made in patch 1 and avx2 to vf_tinterlace.

Regards,
Thomas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] avfilter/x86/vf_interlace : fix crash if unaligned data (ticket 6491)

[Thomas Mundt]

2017-12-14 21:33 GMT+01:00 Thomas Mundt <tmund...@gmail.com>:

> Hi,
>
> 2017-12-14 17:01 GMT+01:00 Martin Vignali <martin.vign...@gmail.com>:
>
>> Hello,
>>
>>
>> in attach patch to fix crash using this command line
>> ./ffmpeg -f lavfi -i testsrc=s=hd1080,format=yuv420p -vf
>> crop=1440:1080,interlace -f null -
>> (ticket 6491)
>>
>> Use unaligned load, to avoid crash
>>
>
> this changes the color planes when zscale filter is in front.
>

Sorry, I mixed up some libraries. Please ignore my last mail.
Patch LGTM, thanks!

Regards,
Thomas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] avfilter/x86/vf_interlace : fix crash in low_pass_complex

[Thomas Mundt]

Hi,

2017-12-14 17:58 GMT+01:00 Martin Vignali :

> Hello,
>
> related to ticket 6491 (crash using crop and vf_interlace)
>
> in attach patch to fix crash when data are unaligned, with low_pass_complex
> filtering
> (the previous patch, fix crash, for low_pass_simple filtering)
>
>
> Can be test with
> For 8 bits
> ./ffmpeg -f lavfi -i testsrc=s=hd1080,format=yuv420p -vf
> crop=1440:1080,interlace=lowpass=2 -f null -
>
> For > 8 bits :
> ./ffmpeg -f lavfi -i testsrc=s=hd1080,format=yuv420p10le -vf
> crop=1442:1080,interlace=lowpass=2 -f null -
>
> i use m2 as temp xmm, in order to make an unaligned load (m2 is not use in
> the last part of the loop, and overide at the start of the loop)
>
> and in complex_12bits filtering
> i use m4, for the same reason
>

Patch LGTM, thanks!

Regards,
Thomas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] avfilter/x86/vf_interlace : fix crash if unaligned data (ticket 6491)

[Thomas Mundt]

Hi,

2017-12-14 17:01 GMT+01:00 Martin Vignali :

> Hello,
>
>
> in attach patch to fix crash using this command line
> ./ffmpeg -f lavfi -i testsrc=s=hd1080,format=yuv420p -vf
> crop=1440:1080,interlace -f null -
> (ticket 6491)
>
> Use unaligned load, to avoid crash
>

this changes the color planes when zscale filter is in front.
Compare this command line output with and without your patch:
ffmpeg -f lavfi -i testsrc=s=hd1080,format=yuv420p -vf
zscale,interlace -c:v mpeg2video -t 5 test.mpg

Regards,
Thomas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] R: [PATCH] MXF format fix for Sony Station compatibility

[Thomas Mundt]

2017-10-24 12:35 GMT+02:00 :

> >From 2a657145a9b6bc2c1beb450100fe2d4d80ee Mon Sep 17 00:00:00 2001
> From: "Axel Technology" 
> Date: Mon, 23 Oct 2017 18:02:58 +0200
> Subject: [PATCH] Sony XDCAM Fix
>
> Signed-off-by: Axel Technology 
> ---
>  libavformat/mxfenc.c | 112 
> ++-
>  1 file changed, 66 insertions(+), 46 deletions(-)
>
>  [...]

> -// MPEG video Descriptor
> -{ 0x8000, 
> {0x06,0x0E,0x2B,0x34,0x01,0x01,0x01,0x05,0x04,0x01,0x06,0x02,0x01,0x0B,0x00,0x00}},
>  /* BitRate */
> -{ 0x8007, 
> {0x06,0x0E,0x2B,0x34,0x01,0x01,0x01,0x05,0x04,0x01,0x06,0x02,0x01,0x0A,0x00,0x00}},
>  /* ProfileAndLevel */
> +{ 0x8003, 
> {0x06,0x0E,0x2B,0x34,0x01,0x01,0x01,0x05,0x04,0x01,0x06,0x02,0x01,0x05,0x00,0x00}},
>  /* LowDelay */
> +{ 0x8004, 
> {0x06,0x0E,0x2B,0x34,0x01,0x01,0x01,0x05,0x04,0x01,0x06,0x02,0x01,0x06,0x00,0x00}},
>  /* ClosedGOP */
> +{ 0x8006, 
> {0x06,0x0E,0x2B,0x34,0x01,0x01,0x01,0x05,0x04,0x01,0x06,0x02,0x01,0x08,0x00,0x00}},
>  /* MaxGOP */
> +{ 0x8007, 
> {0x06,0x0E,0x2B,0x34,0x01,0x01,0x01,0x05,0x04,0x01,0x06,0x02,0x01,0x09,0x00,0x00}},
>  /* BPictureCount */
> +{ 0x8008, 
> {0x06,0x0E,0x2B,0x34,0x01,0x01,0x01,0x05,0x04,0x01,0x06,0x02,0x01,0x0A,0x00,0x00}},
>  /* ProfileAndLevel*/
> +{ 0x8009, 
> {0x06,0x0E,0x2B,0x34,0x01,0x01,0x01,0x05,0x04,0x01,0x06,0x02,0x01,0x0B,0x00,0x00}},
>  /* BitRate */
>
>
You modified the tags for BitRate and ProfileAndLevel, but didn´t adapt the
mxf_write_mpegvideo_desc function. The other UIDs you added aren´t used
elsewhere.
They could be used within the mxf_write_mpegvideo_desc function function,
as Maksym did in his patch.

@@ -1823,7 +1838,6 @@ static const struct {
>  int profile;
>  uint8_t interlaced;
>  } mxf_h264_codec_uls[] = {
> -{{ 
> 0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x0a,0x04,0x01,0x02,0x02,0x01,0x31,0x11,0x01
>  },  0,  66, 0 }, // AVC Baseline, Unconstrained Coding
>
>
This seems unrelated. In any case AVC Baseline support should not be
dropped.

@@ -2254,6 +2273,7 @@ static void mxf_write_system_item(AVFormatContext *s)
>  avio_w8(pb, 0x00); // content package type
>  avio_wb16(pb, 0x00); // channel handle
>  avio_wb16(pb, (mxf->tc.start + frame) & 0x); // continuity count, 
> supposed to overflow
> +avio_wb16(pb, mxf->last_indexed_edit_unit + mxf->edit_units_count); // 
> continuity count
>
>
This looks wrong to me. Is it intended to write continuity count twice?

But I´m not an mxf expert.
Someone with more experience should have a look at this patch.

Regards,
Thomas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] ffmpeg.c: Fallback to duration_dts, when duration_pts can't be determined.

[Thomas Mundt]

Hi Michael,

2017-10-12 1:28 GMT+02:00 Michael Niedermayer <mich...@niedermayer.cc>:

> On Tue, Oct 10, 2017 at 10:26:13PM +0200, Thomas Mundt wrote:
> > 2017-10-10 19:36 GMT+02:00 Sasi Inguva <isasi-at-google@ffmpeg.org>:
> >
> > > This is required for FLV files, for which duration_pts comes out to be
> > > zero.
> > >
> > > Signed-off-by: Sasi Inguva <is...@google.com>
> > > ---
> > >  fftools/ffmpeg.c | 9 +++--
> > >  1 file changed, 7 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
> > > index 6d64bc1043..3ee31473dc 100644
> > > --- a/fftools/ffmpeg.c
> > > +++ b/fftools/ffmpeg.c
> > > @@ -2665,8 +2665,13 @@ static int process_input_packet(InputStream
> *ist,
> > > const AVPacket *pkt, int no_eo
> > >  ist->next_dts = AV_NOPTS_VALUE;
> > >  }
> > >
> > > -if (got_output)
> > > -ist->next_pts += av_rescale_q(duration_pts,
> > > ist->st->time_base, AV_TIME_BASE_Q);
> > > +if (got_output) {
> > > +if (duration_pts > 0) {
> > > +ist->next_pts += av_rescale_q(duration_pts,
> > > ist->st->time_base, AV_TIME_BASE_Q);
> > > +} else {
> > > +ist->next_pts += duration_dts;
> > > +}
> > > +}
> > >  break;
> > >  case AVMEDIA_TYPE_SUBTITLE:
> > >  if (repeating)
> > > --
> > >
> >
> > Patch LGTM.
>
> will apply
>

would you mind pushing this patch to the 3.4 branch also?

Thank you,
Thomas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] ffmpeg.c: Fallback to duration_dts, when duration_pts can't be determined.

[Thomas Mundt]

2017-10-10 19:36 GMT+02:00 Sasi Inguva :

> This is required for FLV files, for which duration_pts comes out to be
> zero.
>
> Signed-off-by: Sasi Inguva 
> ---
>  fftools/ffmpeg.c | 9 +++--
>  1 file changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
> index 6d64bc1043..3ee31473dc 100644
> --- a/fftools/ffmpeg.c
> +++ b/fftools/ffmpeg.c
> @@ -2665,8 +2665,13 @@ static int process_input_packet(InputStream *ist,
> const AVPacket *pkt, int no_eo
>  ist->next_dts = AV_NOPTS_VALUE;
>  }
>
> -if (got_output)
> -ist->next_pts += av_rescale_q(duration_pts,
> ist->st->time_base, AV_TIME_BASE_Q);
> +if (got_output) {
> +if (duration_pts > 0) {
> +ist->next_pts += av_rescale_q(duration_pts,
> ist->st->time_base, AV_TIME_BASE_Q);
> +} else {
> +ist->next_pts += duration_dts;
> +}
> +}
>  break;
>  case AVMEDIA_TYPE_SUBTITLE:
>  if (repeating)
> --
>

Patch LGTM.
Since before commit 36c111c40f4bd7da114df0e9c484833aa2cdf2dc duration_dts
was generally used here, it should be ok as fallback.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] lavfi/avfilter.c: Correct guess_status_pts to account for differing link timebases.

[Thomas Mundt]

2017-10-06 10:01 GMT+02:00 Nicolas George :

> Le quartidi 14 vendémiaire, an CCXXVI, Sasi Inguva a écrit :
> > Signed-off-by: Sasi Inguva 
> > ---
> >  libavfilter/avfilter.c | 16 
> >  1 file changed, 8 insertions(+), 8 deletions(-)
>
> You are right, this change is needed. Thanks for spotting it and the
> patch.
>
> >
> > diff --git a/libavfilter/avfilter.c b/libavfilter/avfilter.c
> > index 58917ed445..ec7dfc0bd3 100644
> > --- a/libavfilter/avfilter.c
> > +++ b/libavfilter/avfilter.c
> > @@ -427,19 +427,19 @@ int ff_request_frame(AVFilterLink *link)
> >  return 0;
> >  }
> >
>
> > -static int64_t guess_status_pts(AVFilterContext *ctx, int status)
> > +static int64_t guess_status_pts_from_src(AVFilterLink *link, int
> status)
>
> I would prefer if you just added a "AVRational time_base" parameter.
> With this version, the code has "link->" indirections all over the
> place, that lowers the readability.
>
> >  {
> >  unsigned i;
> >  int64_t r = INT64_MAX;
> >
> > -for (i = 0; i < ctx->nb_inputs; i++)
> > -if (ctx->inputs[i]->status_out == status)
> > -r = FFMIN(r, ctx->inputs[i]->current_pts);
> > +for (i = 0; i < link->src->nb_inputs; i++)
> > +if (link->src->inputs[i]->status_out == status)
> > +  r = FFMIN(r, av_rescale_q(link->src->inputs[i]->current_pts,
> link->src->inputs[i]->time_base, link->time_base));
> >  if (r < INT64_MAX)
> >  return r;
> > -av_log(ctx, AV_LOG_WARNING, "EOF timestamp not reliable\n");
> > -for (i = 0; i < ctx->nb_inputs; i++)
> > -r = FFMIN(r, ctx->inputs[i]->status_in_pts);
> > +av_log(link->src, AV_LOG_WARNING, "EOF timestamp not reliable\n");
> > +for (i = 0; i < link->src->nb_inputs; i++)
> > +  r = FFMIN(r, av_rescale_q(link->src->inputs[i]->status_in_pts,
> link->src->inputs[i]->time_base, link->time_base));
> >  if (r < INT64_MAX)
> >  return r;
> >  return AV_NOPTS_VALUE;
> > @@ -458,7 +458,7 @@ static int ff_request_frame_to_filter(AVFilterLink
> *link)
> >  ret = ff_request_frame(link->src->inputs[0]);
> >  if (ret < 0) {
> >  if (ret != AVERROR(EAGAIN) && ret != link->status_in)
> > -ff_avfilter_link_set_in_status(link, ret,
> guess_status_pts(link->src, ret));
> > +ff_avfilter_link_set_in_status(link, ret,
> guess_status_pts_from_src(link, ret));
> >  if (ret == AVERROR_EOF)
> >  ret = 0;
> >  }
>

It would be great if this fix will find its way into FFmpeg 3.4.

Thank you,
Thomas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] lavfi/avfilter.c: Correct guess_status_pts to account for differing link timebases.

[Thomas Mundt]

2017-10-06 4:49 GMT+02:00 Sasi Inguva :

> Signed-off-by: Sasi Inguva 
> ---
>  libavfilter/avfilter.c | 16 
>  1 file changed, 8 insertions(+), 8 deletions(-)
>
> diff --git a/libavfilter/avfilter.c b/libavfilter/avfilter.c
> index 58917ed445..ec7dfc0bd3 100644
> --- a/libavfilter/avfilter.c
> +++ b/libavfilter/avfilter.c
> @@ -427,19 +427,19 @@ int ff_request_frame(AVFilterLink *link)
>  return 0;
>  }
>
> -static int64_t guess_status_pts(AVFilterContext *ctx, int status)
> +static int64_t guess_status_pts_from_src(AVFilterLink *link, int status)
>  {
>  unsigned i;
>  int64_t r = INT64_MAX;
>
> -for (i = 0; i < ctx->nb_inputs; i++)
> -if (ctx->inputs[i]->status_out == status)
> -r = FFMIN(r, ctx->inputs[i]->current_pts);
> +for (i = 0; i < link->src->nb_inputs; i++)
> +if (link->src->inputs[i]->status_out == status)
> +  r = FFMIN(r, av_rescale_q(link->src->inputs[i]->current_pts,
> link->src->inputs[i]->time_base, link->time_base));
>  if (r < INT64_MAX)
>  return r;
> -av_log(ctx, AV_LOG_WARNING, "EOF timestamp not reliable\n");
> -for (i = 0; i < ctx->nb_inputs; i++)
> -r = FFMIN(r, ctx->inputs[i]->status_in_pts);
> +av_log(link->src, AV_LOG_WARNING, "EOF timestamp not reliable\n");
> +for (i = 0; i < link->src->nb_inputs; i++)
> +  r = FFMIN(r, av_rescale_q(link->src->inputs[i]->status_in_pts,
> link->src->inputs[i]->time_base, link->time_base));
>  if (r < INT64_MAX)
>  return r;
>  return AV_NOPTS_VALUE;
> @@ -458,7 +458,7 @@ static int ff_request_frame_to_filter(AVFilterLink
> *link)
>  ret = ff_request_frame(link->src->inputs[0]);
>  if (ret < 0) {
>  if (ret != AVERROR(EAGAIN) && ret != link->status_in)
> -ff_avfilter_link_set_in_status(link, ret,
> guess_status_pts(link->src, ret));
> +ff_avfilter_link_set_in_status(link, ret,
> guess_status_pts_from_src(link, ret));
>  if (ret == AVERROR_EOF)
>  ret = 0;
>  }
>

Thank you for this patch. Works fine for me.

Regards,
Thomas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 5/5] ffmpeg: send EOF pts to filters.

[Thomas Mundt]

Hi Nicolas,

2017-09-07 10:59 GMT+02:00 Nicolas George :

> Signed-off-by: Nicolas George 
> ---
>  ffmpeg.c | 10 +++---
>  1 file changed, 7 insertions(+), 3 deletions(-)
>
> diff --git a/ffmpeg.c b/ffmpeg.c
> index b95addd277..1d248bc269 100644
> --- a/ffmpeg.c
> +++ b/ffmpeg.c
> @@ -2223,14 +2223,14 @@ static int ifilter_send_frame(InputFilter
> *ifilter, AVFrame *frame)
>  return 0;
>  }
>
> -static int ifilter_send_eof(InputFilter *ifilter)
> +static int ifilter_send_eof(InputFilter *ifilter, int64_t pts)
>  {
>  int i, j, ret;
>
>  ifilter->eof = 1;
>
>  if (ifilter->filter) {
> -ret = av_buffersrc_add_frame_flags(ifilter->filter, NULL,
> AV_BUFFERSRC_FLAG_PUSH);
> +ret = av_buffersrc_close(ifilter->filter, pts,
> AV_BUFFERSRC_FLAG_PUSH);
>  if (ret < 0)
>  return ret;
>  } else {
> @@ -2581,8 +2581,12 @@ out:
>  static int send_filter_eof(InputStream *ist)
>  {
>  int i, ret;
> +/* TODO keep pts also in stream time base to avoid converting back */
> +int64_t pts = av_rescale_q_rnd(ist->pts, AV_TIME_BASE_Q,
> ist->st->time_base,
> +   AV_ROUND_NEAR_INF |
> AV_ROUND_PASS_MINMAX);
> +
>  for (i = 0; i < ist->nb_filters; i++) {
> -ret = ifilter_send_eof(ist->filters[i]);
> +ret = ifilter_send_eof(ist->filters[i], pts);
>  if (ret < 0)
>  return ret;
>  }
>

The sended pts always seems to refer to the input time base.
When a filter changes the time base, the EOF pts becomes wrong for
subsequent filters in the chain.
E.g. when using vf_fps behind vf_yadif=1 with interlaced input, the sended
EOF pts is only half of the expected pts.

I tried to find a solution, but without success.
Do you have an idea?

Regards,
Thomas



Virenfrei.
www.avg.com

<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avfilter/interlace: rename two variables for consistency

[Thomas Mundt]

2017-09-19 22:54 GMT+02:00 Thomas Mundt <tmund...@gmail.com>:

> The attached patch needs to be applied on top of
> "avfilter/interlace: add support for 10 and 12 bit".
> Thanks.
>

Ping
This patch is needful cosmetic after last commit.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 3/3 v2] avfilter/interlace: add support for 10 and 12 bit

[Thomas Mundt]

2017-09-23 20:24 GMT+02:00 Michael Niedermayer <mich...@niedermayer.cc>:

> On Tue, Sep 19, 2017 at 10:35:30PM +0200, Thomas Mundt wrote:
> > 2017-09-19 17:53 GMT+02:00 James Almer <jamr...@gmail.com>:
> >
> > > On 9/19/2017 5:02 AM, Thomas Mundt wrote:
> > > > 2017-09-19 4:09 GMT+02:00 James Almer <jamr...@gmail.com>:
> > > >
> > > >> On 9/18/2017 10:41 PM, Thomas Mundt wrote:
> > > >>> I tried to set up MIPS compiler for two days on windows and linux
> > > without
> > > >>> success.
> > > >>> Now I try it blind. This solution is based on the first suggestion
> > > James
> > > >>> gave me at IRC.
> > > >>> There might be room for improvement and an alternative solution
> with
> > > >>> AV_RL16() / AV_WL16().
> > > >>> I used av_le2ne16() because it will be ignored for little endian.
> > > >>>
> > > >>> Regards,
> > > >>> Thomas
> > > >>
> > > >>> From a2be5859266b1a2f7048b81ced6770ab4b90a5a4 Mon Sep 17 00:00:00
> 2001
> > > >>> From: Thomas Mundt <tmund...@gmail.com>
> > > >>> Date: Tue, 19 Sep 2017 00:25:25 +0200
> > > >>> Subject: [PATCH 3/3 v2] avfilter/interlace: add support for 10 and
> 12
> > > bit
> > > >>>
> > > >>> Signed-off-by: Thomas Mundt <tmund...@gmail.com>
> > > >>> ---
> > > >>>  libavfilter/interlace.h|  5 +-
> > > >>>  libavfilter/tinterlace.h   |  5 +-
> > > >>>  libavfilter/vf_interlace.c | 92
> > > >> ++
> > > >>>  libavfilter/vf_tinterlace.c| 73
> > > ++--
> > > >>>  libavfilter/x86/vf_interlace.asm   | 80
> > > >> --
> > > >>>  libavfilter/x86/vf_interlace_init.c| 51
> ++
> > > >>>  libavfilter/x86/vf_tinterlace_init.c   | 51
> ++
> > > >>>  tests/ref/fate/filter-pixfmts-tinterlace_cvlpf | 11 +++
> > > >>>  tests/ref/fate/filter-pixfmts-tinterlace_merge | 11 +++
> > > >>>  tests/ref/fate/filter-pixfmts-tinterlace_pad   | 11 +++
> > > >>>  tests/ref/fate/filter-pixfmts-tinterlace_vlpf  | 11 +++
> > > >>>  11 files changed, 345 insertions(+), 56 deletions(-)
> > > >>>
> > > >>> diff --git a/libavfilter/interlace.h b/libavfilter/interlace.h
> > > >>> index 2101b79..90a0198 100644
> > > >>> --- a/libavfilter/interlace.h
> > > >>> +++ b/libavfilter/interlace.h
> > > >>> @@ -25,9 +25,11 @@
> > > >>>  #ifndef AVFILTER_INTERLACE_H
> > > >>>  #define AVFILTER_INTERLACE_H
> > > >>>
> > > >>> +#include "libavutil/bswap.h"
> > > >>>  #include "libavutil/common.h"
> > > >>>  #include "libavutil/imgutils.h"
> > > >>>  #include "libavutil/opt.h"
> > > >>> +#include "libavutil/pixdesc.h"
> > > >>>
> > > >>>  #include "avfilter.h"
> > > >>>  #include "formats.h"
> > > >>> @@ -55,8 +57,9 @@ typedef struct InterlaceContext {
> > > >>>  enum ScanMode scan;// top or bottom field first scanning
> > > >>>  int lowpass;   // enable or disable low pass filtering
> > > >>>  AVFrame *cur, *next;   // the two frames from which the new
> one is
> > > >> obtained
> > > >>> +const AVPixFmtDescriptor *csp;
> > > >>>  void (*lowpass_line)(uint8_t *dstp, ptrdiff_t linesize, const
> > > >> uint8_t *srcp,
> > > >>> - ptrdiff_t mref, ptrdiff_t pref);
> > > >>> + ptrdiff_t mref, ptrdiff_t pref, int
> > > clip_max);
> > > >>>  } InterlaceContext;
> > > >>>
> > > >>>  void ff_interlace_init_x86(InterlaceContext *interlace);
> > > >>> diff --git a/libavfilter/tinterlace.h b/libavfilter/tinterlace.h
> > > >>> index cc13a6c..b5c39aa 100644
> > > >>> -

[FFmpeg-devel] [PATCH] avfilter/interlace: rename two variables for consistency

[Thomas Mundt]

The attached patch needs to be applied on top of
"avfilter/interlace: add support for 10 and 12 bit".
Thanks.


0001-avfilter-interlace-rename-two-variables-for-consiste.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 3/3 v2] avfilter/interlace: add support for 10 and 12 bit

[Thomas Mundt]

2017-09-19 17:53 GMT+02:00 James Almer <jamr...@gmail.com>:

> On 9/19/2017 5:02 AM, Thomas Mundt wrote:
> > 2017-09-19 4:09 GMT+02:00 James Almer <jamr...@gmail.com>:
> >
> >> On 9/18/2017 10:41 PM, Thomas Mundt wrote:
> >>> I tried to set up MIPS compiler for two days on windows and linux
> without
> >>> success.
> >>> Now I try it blind. This solution is based on the first suggestion
> James
> >>> gave me at IRC.
> >>> There might be room for improvement and an alternative solution with
> >>> AV_RL16() / AV_WL16().
> >>> I used av_le2ne16() because it will be ignored for little endian.
> >>>
> >>> Regards,
> >>> Thomas
> >>
> >>> From a2be5859266b1a2f7048b81ced6770ab4b90a5a4 Mon Sep 17 00:00:00 2001
> >>> From: Thomas Mundt <tmund...@gmail.com>
> >>> Date: Tue, 19 Sep 2017 00:25:25 +0200
> >>> Subject: [PATCH 3/3 v2] avfilter/interlace: add support for 10 and 12
> bit
> >>>
> >>> Signed-off-by: Thomas Mundt <tmund...@gmail.com>
> >>> ---
> >>>  libavfilter/interlace.h|  5 +-
> >>>  libavfilter/tinterlace.h   |  5 +-
> >>>  libavfilter/vf_interlace.c | 92
> >> ++
> >>>  libavfilter/vf_tinterlace.c| 73
> ++--
> >>>  libavfilter/x86/vf_interlace.asm   | 80
> >> --
> >>>  libavfilter/x86/vf_interlace_init.c| 51 ++
> >>>  libavfilter/x86/vf_tinterlace_init.c   | 51 ++
> >>>  tests/ref/fate/filter-pixfmts-tinterlace_cvlpf | 11 +++
> >>>  tests/ref/fate/filter-pixfmts-tinterlace_merge | 11 +++
> >>>  tests/ref/fate/filter-pixfmts-tinterlace_pad   | 11 +++
> >>>  tests/ref/fate/filter-pixfmts-tinterlace_vlpf  | 11 +++
> >>>  11 files changed, 345 insertions(+), 56 deletions(-)
> >>>
> >>> diff --git a/libavfilter/interlace.h b/libavfilter/interlace.h
> >>> index 2101b79..90a0198 100644
> >>> --- a/libavfilter/interlace.h
> >>> +++ b/libavfilter/interlace.h
> >>> @@ -25,9 +25,11 @@
> >>>  #ifndef AVFILTER_INTERLACE_H
> >>>  #define AVFILTER_INTERLACE_H
> >>>
> >>> +#include "libavutil/bswap.h"
> >>>  #include "libavutil/common.h"
> >>>  #include "libavutil/imgutils.h"
> >>>  #include "libavutil/opt.h"
> >>> +#include "libavutil/pixdesc.h"
> >>>
> >>>  #include "avfilter.h"
> >>>  #include "formats.h"
> >>> @@ -55,8 +57,9 @@ typedef struct InterlaceContext {
> >>>  enum ScanMode scan;// top or bottom field first scanning
> >>>  int lowpass;   // enable or disable low pass filtering
> >>>  AVFrame *cur, *next;   // the two frames from which the new one is
> >> obtained
> >>> +const AVPixFmtDescriptor *csp;
> >>>  void (*lowpass_line)(uint8_t *dstp, ptrdiff_t linesize, const
> >> uint8_t *srcp,
> >>> - ptrdiff_t mref, ptrdiff_t pref);
> >>> + ptrdiff_t mref, ptrdiff_t pref, int
> clip_max);
> >>>  } InterlaceContext;
> >>>
> >>>  void ff_interlace_init_x86(InterlaceContext *interlace);
> >>> diff --git a/libavfilter/tinterlace.h b/libavfilter/tinterlace.h
> >>> index cc13a6c..b5c39aa 100644
> >>> --- a/libavfilter/tinterlace.h
> >>> +++ b/libavfilter/tinterlace.h
> >>> @@ -27,7 +27,9 @@
> >>>  #ifndef AVFILTER_TINTERLACE_H
> >>>  #define AVFILTER_TINTERLACE_H
> >>>
> >>> +#include "libavutil/bswap.h"
> >>>  #include "libavutil/opt.h"
> >>> +#include "libavutil/pixdesc.h"
> >>>  #include "drawutils.h"
> >>>  #include "avfilter.h"
> >>>
> >>> @@ -60,8 +62,9 @@ typedef struct TInterlaceContext {
> >>>  int black_linesize[4];
> >>>  FFDrawContext draw;
> >>>  FFDrawColor color;
> >>> +const AVPixFmtDescriptor *csp;
> >>>  void (*lowpass_line)(uint8_t *dstp, ptrdiff_t width, const uint8_t
> >> *srcp,
> >>> - ptrdiff_t mref, ptrdiff_t pref);

Re: [FFmpeg-devel] [PATCH 3/3 v2] avfilter/interlace: add support for 10 and 12 bit

[Thomas Mundt]

2017-09-19 4:09 GMT+02:00 James Almer <jamr...@gmail.com>:

> On 9/18/2017 10:41 PM, Thomas Mundt wrote:
> > I tried to set up MIPS compiler for two days on windows and linux without
> > success.
> > Now I try it blind. This solution is based on the first suggestion James
> > gave me at IRC.
> > There might be room for improvement and an alternative solution with
> > AV_RL16() / AV_WL16().
> > I used av_le2ne16() because it will be ignored for little endian.
> >
> > Regards,
> > Thomas
>
> > From a2be5859266b1a2f7048b81ced6770ab4b90a5a4 Mon Sep 17 00:00:00 2001
> > From: Thomas Mundt <tmund...@gmail.com>
> > Date: Tue, 19 Sep 2017 00:25:25 +0200
> > Subject: [PATCH 3/3 v2] avfilter/interlace: add support for 10 and 12 bit
> >
> > Signed-off-by: Thomas Mundt <tmund...@gmail.com>
> > ---
> >  libavfilter/interlace.h|  5 +-
> >  libavfilter/tinterlace.h   |  5 +-
> >  libavfilter/vf_interlace.c | 92
> ++
> >  libavfilter/vf_tinterlace.c| 73 ++--
> >  libavfilter/x86/vf_interlace.asm   | 80
> --
> >  libavfilter/x86/vf_interlace_init.c| 51 ++
> >  libavfilter/x86/vf_tinterlace_init.c   | 51 ++
> >  tests/ref/fate/filter-pixfmts-tinterlace_cvlpf | 11 +++
> >  tests/ref/fate/filter-pixfmts-tinterlace_merge | 11 +++
> >  tests/ref/fate/filter-pixfmts-tinterlace_pad   | 11 +++
> >  tests/ref/fate/filter-pixfmts-tinterlace_vlpf  | 11 +++
> >  11 files changed, 345 insertions(+), 56 deletions(-)
> >
> > diff --git a/libavfilter/interlace.h b/libavfilter/interlace.h
> > index 2101b79..90a0198 100644
> > --- a/libavfilter/interlace.h
> > +++ b/libavfilter/interlace.h
> > @@ -25,9 +25,11 @@
> >  #ifndef AVFILTER_INTERLACE_H
> >  #define AVFILTER_INTERLACE_H
> >
> > +#include "libavutil/bswap.h"
> >  #include "libavutil/common.h"
> >  #include "libavutil/imgutils.h"
> >  #include "libavutil/opt.h"
> > +#include "libavutil/pixdesc.h"
> >
> >  #include "avfilter.h"
> >  #include "formats.h"
> > @@ -55,8 +57,9 @@ typedef struct InterlaceContext {
> >  enum ScanMode scan;// top or bottom field first scanning
> >  int lowpass;   // enable or disable low pass filtering
> >  AVFrame *cur, *next;   // the two frames from which the new one is
> obtained
> > +const AVPixFmtDescriptor *csp;
> >  void (*lowpass_line)(uint8_t *dstp, ptrdiff_t linesize, const
> uint8_t *srcp,
> > - ptrdiff_t mref, ptrdiff_t pref);
> > + ptrdiff_t mref, ptrdiff_t pref, int clip_max);
> >  } InterlaceContext;
> >
> >  void ff_interlace_init_x86(InterlaceContext *interlace);
> > diff --git a/libavfilter/tinterlace.h b/libavfilter/tinterlace.h
> > index cc13a6c..b5c39aa 100644
> > --- a/libavfilter/tinterlace.h
> > +++ b/libavfilter/tinterlace.h
> > @@ -27,7 +27,9 @@
> >  #ifndef AVFILTER_TINTERLACE_H
> >  #define AVFILTER_TINTERLACE_H
> >
> > +#include "libavutil/bswap.h"
> >  #include "libavutil/opt.h"
> > +#include "libavutil/pixdesc.h"
> >  #include "drawutils.h"
> >  #include "avfilter.h"
> >
> > @@ -60,8 +62,9 @@ typedef struct TInterlaceContext {
> >  int black_linesize[4];
> >  FFDrawContext draw;
> >  FFDrawColor color;
> > +const AVPixFmtDescriptor *csp;
> >  void (*lowpass_line)(uint8_t *dstp, ptrdiff_t width, const uint8_t
> *srcp,
> > - ptrdiff_t mref, ptrdiff_t pref);
> > + ptrdiff_t mref, ptrdiff_t pref, int clip_max);
> >  } TInterlaceContext;
> >
> >  void ff_tinterlace_init_x86(TInterlaceContext *interlace);
> > diff --git a/libavfilter/vf_interlace.c b/libavfilter/vf_interlace.c
> > index 55bf782..bfba054 100644
> > --- a/libavfilter/vf_interlace.c
> > +++ b/libavfilter/vf_interlace.c
> > @@ -61,8 +61,8 @@ static const AVOption interlace_options[] = {
> >  AVFILTER_DEFINE_CLASS(interlace);
> >
> >  static void lowpass_line_c(uint8_t *dstp, ptrdiff_t linesize,
> > -   const uint8_t *srcp,
> > -   ptrdiff_t mref, ptrdiff_t pref)
> > +   const uint8_t *srcp, ptrdiff_t mref,
> > +  

[FFmpeg-devel] [PATCH 3/3 v2] avfilter/interlace: add support for 10 and 12 bit

[Thomas Mundt]

I tried to set up MIPS compiler for two days on windows and linux without
success.
Now I try it blind. This solution is based on the first suggestion James
gave me at IRC.
There might be room for improvement and an alternative solution with
AV_RL16() / AV_WL16().
I used av_le2ne16() because it will be ignored for little endian.

Regards,
Thomas


0003-avfilter-interlace-add-support-for-10-and-12-bit.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 2/3 v2] avfilter/tinterlace: use drawutils for pad mode

[Thomas Mundt]

Patch 1/3 has already been applied.
Patch attached.


0002-avfilter-tinterlace-use-drawutils-for-pad-mode.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] MAINTAINERS: add myself for bwdif and (t)interlace

[Thomas Mundt]

Requested by Michael


0001-MAINTAINERS-add-myself-for-bwdif-and-t-interlace.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 3/3] avfilter/interlace: add support for 10 and 12 bit

[Thomas Mundt]

2017-09-15 22:15 GMT+02:00 Michael Niedermayer <mich...@niedermayer.cc>:

> On Thu, Sep 14, 2017 at 10:58:01PM +0200, Thomas Mundt wrote:
>
> > Patch attached
>
>
>
> >  libavfilter/interlace.h|4 -
>
> >  libavfilter/tinterlace.h   |4 -
>
> >  libavfilter/vf_interlace.c |   89
> +
>
> >  libavfilter/vf_tinterlace.c|   70
> ++-
>
> >  libavfilter/x86/vf_interlace.asm   |   80
> --
>
> >  libavfilter/x86/vf_interlace_init.c|   51 ++
>
> >  libavfilter/x86/vf_tinterlace_init.c   |   51 ++
>
> >  tests/fate/filter-video.mak|6 +
>
> >  tests/ref/fate/filter-pixfmts-tinterlace_cvlpf |   25 +++
>
> >  tests/ref/fate/filter-pixfmts-tinterlace_merge |   11 +++
>
> >  tests/ref/fate/filter-pixfmts-tinterlace_pad   |   11 +++
>
> >  tests/ref/fate/filter-pixfmts-tinterlace_vlpf  |   25 +++
>
> >  12 files changed, 371 insertions(+), 56 deletions(-)
>
> > a31ca544a0bcbcc2e1bb5252dff236e778f134c1  0003-avfilter-interlace-add-
> support-for-10-and-12-bit.patch
>
> > From b3af963fda7b78d91cbf5b3aea2ad595666f5c4c Mon Sep 17 00:00:00 2001
>
> > From: Thomas Mundt <tmund...@gmail.com>
>
> > Date: Thu, 14 Sep 2017 21:25:27 +0200
>
> > Subject: [PATCH 3/3] avfilter/interlace: add support for 10 and 12 bit
>
> >
>
> > Signed-off-by: Thomas Mundt <tmund...@gmail.com>
>
> > ---
>
> >  libavfilter/interlace.h|  4 +-
>
> >  libavfilter/tinterlace.h   |  4 +-
>
> >  libavfilter/vf_interlace.c | 89
> ++
>
> >  libavfilter/vf_tinterlace.c| 70 ++--
>
> >  libavfilter/x86/vf_interlace.asm   | 80
> +--
>
> >  libavfilter/x86/vf_interlace_init.c| 51 +++
>
> >  libavfilter/x86/vf_tinterlace_init.c   | 51 +++
>
> >  tests/fate/filter-video.mak|  6 ++
>
> >  tests/ref/fate/filter-pixfmts-tinterlace_cvlpf | 25 
>
> >  tests/ref/fate/filter-pixfmts-tinterlace_merge | 11 
>
> >  tests/ref/fate/filter-pixfmts-tinterlace_pad   | 11 
>
> >  tests/ref/fate/filter-pixfmts-tinterlace_vlpf  | 25 
>
> >  12 files changed, 371 insertions(+), 56 deletions(-)
>
> >  create mode 100644 tests/ref/fate/filter-pixfmts-tinterlace_cvlpf
>
> >  create mode 100644 tests/ref/fate/filter-pixfmts-tinterlace_vlpf
>
>
>
> fails on mips-qemu
>

I don´t have any possibility for testing big endian.
So I limit this patch to LE.
Attached.


0003-avfilter-interlace-add-support-for-10-and-12-bit.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avfilter/interlace: prevent over-sharpening with the complex low-pass filter

[Thomas Mundt]

2017-09-15 22:26 GMT+02:00 Michael Niedermayer <mich...@niedermayer.cc>:

> On Fri, Sep 15, 2017 at 04:38:16PM +0200, Thomas Mundt wrote: >
> > Michael, is it possible for you to push this?
>
> will push
>

Thanks!

also i see noone listed in MAINTAINERS for vf_(t)interlace
> if noone objects, you might want to send a patch that adds you for
> them. It seems you are the most active on these ATM
>

Hmm, I would do this, but I have doubts whether I´m qualified for it.
Coding is just one of my hobbies, though I started using it at work.
Also I´m quite active ATM, but there will be long periods where I won´t
find the time following the ML.
If that´s okay for you, I will do. Maybe I can deposit an alternative email
address, which I check more often?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avfilter/interlace: prevent over-sharpening with the complex low-pass filter

[Thomas Mundt]

2017-09-13 23:35 GMT+02:00 Thomas Mundt <tmund...@gmail.com>:

> 2017-09-06 22:15 GMT+02:00 Thomas Mundt <tmund...@gmail.com>:
>
>> 2017-09-01 1:55 GMT+02:00 Thomas Mundt <tmund...@gmail.com>:
>>
>>> 2017-09-01 1:22 GMT+02:00 Michael Niedermayer <mich...@niedermayer.cc>:
>>>
>>>> On Fri, Sep 01, 2017 at 01:18:11AM +0200, Michael Niedermayer wrote:
>>>> > On Thu, Aug 31, 2017 at 10:40:12PM +0200, Thomas Mundt wrote:
>>>> > > 2017-08-31 21:42 GMT+02:00 Michael Niedermayer
>>>> <mich...@niedermayer.cc>:
>>>> > >
>>>> > > > On Wed, Aug 30, 2017 at 03:54:08AM +0200, Thomas Mundt wrote:
>>>> > > > > Hi,
>>>> > > > >
>>>> > > > > we did a transcoding cascade test at work were over-sharpening
>>>> became
>>>> > > > > visible with the complex low-pass filter. This patch rectifies
>>>> the
>>>> > > > > behaviour.
>>>> > > > >
>>>> > > > > Please comment...
>>>> > > >
>>>> > > > did you perform subjective and or objective tests ?
>>>> > > >
>>>> > > > objective being some metric like PSNR vs correctly sampled data
>>>> > > > subjective being double blind tests with humans about which they
>>>> prefer
>>>> > > >
>>>> > >
>>>> > > The tests have been subjective with a team of video engineers and
>>>> > > technicians with several test files.
>>>> > >
>>>> > > I did a quick SSIM/PSNR check with the first generation of an
>>>> HD->SD file
>>>> > > as a reference against the 6th generation.
>>>> >
>>>> > if its better then iam fine with it. No more comments from me
>>>>
>>>> ahh, forgot, you may want tp add the tests you did and their results
>>>> to the commit message
>>>
>>>
>>> Sure, new patch attached.
>>>
>>
>> Ping
>>
>
> Ping!
>

Michael, is it possible for you to push this?
Or is there anything that I need to do?

Regards, Thomas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 1/3] avfilter/interlace: simplify code

[Thomas Mundt]

Patch attached


0001-avfilter-interlace-simplify-code.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 3/3] avfilter/interlace: add support for 10 and 12 bit

[Thomas Mundt]

Patch attached


0003-avfilter-interlace-add-support-for-10-and-12-bit.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 2/3] avfilter/tinterlace: use drawutils for pad mode

[Thomas Mundt]

Patch attached


0002-avfilter-tinterlace-use-drawutils-for-pad-mode.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 0/3] avfilter/interlace: add support for 10 and 12 bit

[Thomas Mundt]

Hi,

this patch set adds support for 10 and 12 bit to the interlace filters.
This is useful for broadcasters transcoding high bit depth sources to AVC
Intra or similar 10 bit video codecs.
These patches need to be applied on top of the following patch, which is
not pushed yet:
http://ffmpeg.org/pipermail/ffmpeg-devel/2017-September/215621.html

Please comment.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avfilter/interlace: prevent over-sharpening with the complex low-pass filter

[Thomas Mundt]

2017-09-06 22:15 GMT+02:00 Thomas Mundt <tmund...@gmail.com>:

> 2017-09-01 1:55 GMT+02:00 Thomas Mundt <tmund...@gmail.com>:
>
>> 2017-09-01 1:22 GMT+02:00 Michael Niedermayer <mich...@niedermayer.cc>:
>>
>>> On Fri, Sep 01, 2017 at 01:18:11AM +0200, Michael Niedermayer wrote:
>>> > On Thu, Aug 31, 2017 at 10:40:12PM +0200, Thomas Mundt wrote:
>>> > > 2017-08-31 21:42 GMT+02:00 Michael Niedermayer
>>> <mich...@niedermayer.cc>:
>>> > >
>>> > > > On Wed, Aug 30, 2017 at 03:54:08AM +0200, Thomas Mundt wrote:
>>> > > > > Hi,
>>> > > > >
>>> > > > > we did a transcoding cascade test at work were over-sharpening
>>> became
>>> > > > > visible with the complex low-pass filter. This patch rectifies
>>> the
>>> > > > > behaviour.
>>> > > > >
>>> > > > > Please comment...
>>> > > >
>>> > > > did you perform subjective and or objective tests ?
>>> > > >
>>> > > > objective being some metric like PSNR vs correctly sampled data
>>> > > > subjective being double blind tests with humans about which they
>>> prefer
>>> > > >
>>> > >
>>> > > The tests have been subjective with a team of video engineers and
>>> > > technicians with several test files.
>>> > >
>>> > > I did a quick SSIM/PSNR check with the first generation of an HD->SD
>>> file
>>> > > as a reference against the 6th generation.
>>> >
>>> > if its better then iam fine with it. No more comments from me
>>>
>>> ahh, forgot, you may want tp add the tests you did and their results
>>> to the commit message
>>
>>
>> Sure, new patch attached.
>>
>
> Ping
>

Ping!
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] vf_fps: when reading EOF, using current_pts to duplicate the last frame if needed.

[Thomas Mundt]

Hi Thierry,

2017-09-12 3:25 GMT+02:00 Thierry Foucu :

> Fix ticket #2674
> Tested with examples from ticket 2674.
> ---
>
> Update the Patch with the correct number of duplicate showing.
> For exmaple, in case we up-sample one second video at 24fps by 2, we
> should be getting 24 duplicate frames.
>
> ffmpeg -loglevel verbose -i 24fps.avi -vf fps=48 -f null -
> ffmpeg version N-87234-g9a32769f5e Copyright (c) 2000-2017 the FFmpeg
> developers
>   built with gcc 4.8 (Ubuntu 4.8.4-2ubuntu1~14.04.3)
>   configuration:
>   libavutil  55. 74.100 / 55. 74.100
>   libavcodec 57.105.100 / 57.105.100
>   libavformat57. 81.100 / 57. 81.100
>   libavdevice57.  8.100 / 57.  8.100
>   libavfilter 6.103.100 /  6.103.100
>   libswscale  4.  7.103 /  4.  7.103
>   libswresample   2.  8.100 /  2.  8.100
> Input #0, avi, from '24fps.avi':
>   Metadata:
> encoder : Lavf57.81.100
>   Duration: 00:00:01.00, start: 0.00, bitrate: 368 kb/s
> Stream #0:0: Video: mpeg4 (Simple Profile), 1 reference frame (FMP4 /
> 0x34504D46), yuv420p(left), 320x240 [SAR 1:1 DAR 4:3], 24 fps, 24 tbr, 24
> tbn, 24 tbc
> Stream mapping:
>   Stream #0:0 -> #0:0 (mpeg4 (native) -> wrapped_avframe (native))
> Press [q] to stop, [?] for help
> [Parsed_fps_0 @ 0x25ea6a0] fps=48/1
> [graph 0 input from stream 0:0 @ 0x275cc00] w:320 h:240 pixfmt:yuv420p
> tb:1/24 fr:24/1 sar:1/1 sws_param:flags=2
> Output #0, null, to 'pipe:':
>   Metadata:
> encoder : Lavf57.81.100
> Stream #0:0: Video: wrapped_avframe, 1 reference frame, yuv420p(left),
> 320x240 [SAR 1:1 DAR 4:3], q=2-31, 200 kb/s, 48 fps, 48 tbn, 48 tbc
> Metadata:
>   encoder : Lavc57.105.100 wrapped_avframe
> No more output streams to write to, finishing.
> frame=   48 fps=0.0 q=-0.0 Lsize=N/A time=00:00:01.00 bitrate=N/A
> speed=99.3x
> video:25kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB
> muxing overhead: unknown
> Input file #0 (24fps.avi):
>   Input stream #0:0 (video): 24 packets read (39693 bytes); 24 frames
> decoded;
>   Total: 24 packets (39693 bytes) demuxed
> Output file #0 (pipe:):
>   Output stream #0:0 (video): 48 frames encoded; 48 packets muxed (25344
> bytes);
>   Total: 48 packets (25344 bytes) muxed
> [Parsed_fps_0 @ 0x25ea6a0] 24 frames in, 48 frames out; 0 frames dropped,
> 24 frames duplicated.
>
>  libavfilter/vf_fps.c| 44 ++
> +-
>  tests/ref/fate/filter-fps   |  6 ++
>  tests/ref/fate/filter-fps-r |  4 
>  tests/ref/fate/m4v-cfr  |  1 -
>  4 files changed, 49 insertions(+), 6 deletions(-)
>
> diff --git a/libavfilter/vf_fps.c b/libavfilter/vf_fps.c
> index 20ccd797d1..09fc66a73c 100644
> --- a/libavfilter/vf_fps.c
> +++ b/libavfilter/vf_fps.c
> @@ -34,6 +34,8 @@
>  #include "libavutil/opt.h"
>  #include "libavutil/parseutils.h"
>
> +#define FF_INTERNAL_FIELDS 1
> +#include "framequeue.h"
>  #include "avfilter.h"
>  #include "internal.h"
>  #include "video.h"
> @@ -137,13 +139,45 @@ static int request_frame(AVFilterLink *outlink)
>  AVFrame *buf;
>
>  av_fifo_generic_read(s->fifo, , sizeof(buf), NULL);
> -buf->pts = av_rescale_q(s->first_pts,
> ctx->inputs[0]->time_base,
> -outlink->time_base) + s->frames_out;
> +if (av_fifo_size(s->fifo)) {
> +buf->pts = av_rescale_q(s->first_pts,
> ctx->inputs[0]->time_base,
> +outlink->time_base) +
> s->frames_out;
>
> -if ((ret = ff_filter_frame(outlink, buf)) < 0)
> -return ret;
> +if ((ret = ff_filter_frame(outlink, buf)) < 0)
> +return ret;
>
> -s->frames_out++;
> +s->frames_out++;
> +} else {
> +/* This is the last frame, we may have to duplicate it to
> match
> + * the last frame duration */
> +int j;
> +int delta = av_rescale_q_rnd(ctx->inputs[0]->current_pts
> - s->first_pts,
> + ctx->inputs[0]->time_base,
> + outlink->time_base,
> s->rounding) - s->frames_out ;
> +/* if the delta is equal to 1, it means we just need to
> output
> + * the last frame. Greater than 1 means we will need
> duplicate
> + * delta-1 frames */
> +if (delta > 0 ) {
> +for (j = 0; j < delta; j++) {
> +AVFrame *dup = av_frame_clone(buf);
> +
> +av_log(ctx, AV_LOG_DEBUG, "Duplicating frame.\n");
> +dup->pts = av_rescale_q(s->first_pts,
> ctx->inputs[0]->time_base,
> +outlink->time_base) +
> s->frames_out;
> +
> +if ((ret = ff_filter_frame(outlink, dup)) < 0)
> + 

Re: [FFmpeg-devel] [PATCH] vf_fps: when reading EOF, using current_pts to duplicate the last frame if needed.

[Thomas Mundt]

Hi Thierry,

2017-09-11 23:00 GMT+02:00 Thierry Foucu :

> Fix ticket #2674
> Tested with examples from ticket 2674.
> ---
>  libavfilter/vf_fps.c| 40 +++-
>  tests/ref/fate/filter-fps   |  6 ++
>  tests/ref/fate/filter-fps-r |  4 
>  tests/ref/fate/m4v-cfr  |  1 -
>  4 files changed, 45 insertions(+), 6 deletions(-)
>
> diff --git a/libavfilter/vf_fps.c b/libavfilter/vf_fps.c
> index 20ccd797d1..c0d68d8972 100644
> --- a/libavfilter/vf_fps.c
> +++ b/libavfilter/vf_fps.c
> @@ -34,6 +34,8 @@
>  #include "libavutil/opt.h"
>  #include "libavutil/parseutils.h"
>
> +#define FF_INTERNAL_FIELDS 1
> +#include "framequeue.h"
>  #include "avfilter.h"
>  #include "internal.h"
>  #include "video.h"
> @@ -137,13 +139,41 @@ static int request_frame(AVFilterLink *outlink)
>  AVFrame *buf;
>
>  av_fifo_generic_read(s->fifo, , sizeof(buf), NULL);
> -buf->pts = av_rescale_q(s->first_pts,
> ctx->inputs[0]->time_base,
> -outlink->time_base) + s->frames_out;
> +if (av_fifo_size(s->fifo)) {
> +buf->pts = av_rescale_q(s->first_pts,
> ctx->inputs[0]->time_base,
> +outlink->time_base) +
> s->frames_out;
>
> -if ((ret = ff_filter_frame(outlink, buf)) < 0)
> -return ret;
> +if ((ret = ff_filter_frame(outlink, buf)) < 0)
> +return ret;
>
> -s->frames_out++;
> +s->frames_out++;
> +} else {
> +/* This is the last frame, we may have to duplicate it to
> match
> + * the last frame duration */
> +int j;
> +int delta = av_rescale_q_rnd(ctx->inputs[0]->current_pts
> - s->first_pts,
> + ctx->inputs[0]->time_base,
> + outlink->time_base,
> s->rounding) - s->frames_out ;
> +if (delta > 0 ) {
> +for (j = 0; j < delta; j++) {
> +AVFrame *dup = av_frame_clone(buf);
> +
> +av_log(ctx, AV_LOG_DEBUG, "Duplicating frame.\n");
> +dup->pts = av_rescale_q(s->first_pts,
> ctx->inputs[0]->time_base,
> +outlink->time_base) +
> s->frames_out;
> +
> +if ((ret = ff_filter_frame(outlink, dup)) < 0)
> +return ret;
> +
> +s->frames_out++;
>
Duplicated frames are reported to verbose log by the dup variable.
You need to insert something like if(j) s->dup++ here.
Otherwise the log becomes wrong, as in the 48fps example:
Parsed_fps_0 @ 0x34ea4a0] 24 frames in, 48 frames out; 0 frames dropped,
23 frames duplicated.

Anyway, the conversion results are accurate now for any sample I tested.
Thanks.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] vf_fps: when reading EOF, using current_pts to duplicate the last frame if needed.

[Thomas Mundt]

Hi Thierry,

2017-09-08 19:03 GMT+02:00 Thierry Foucu :

> ---
>  libavfilter/vf_fps.c| 42 ++
> +++-
>  tests/ref/fate/filter-fps   |  6 ++
>  tests/ref/fate/filter-fps-r |  4 
>  3 files changed, 47 insertions(+), 5 deletions(-)
>
> diff --git a/libavfilter/vf_fps.c b/libavfilter/vf_fps.c
> index 20ccd797d1..e450723173 100644
> --- a/libavfilter/vf_fps.c
> +++ b/libavfilter/vf_fps.c
> @@ -34,6 +34,8 @@
>  #include "libavutil/opt.h"
>  #include "libavutil/parseutils.h"
>
> +#define FF_INTERNAL_FIELDS 1
> +#include "framequeue.h"
>  #include "avfilter.h"
>  #include "internal.h"
>  #include "video.h"
> @@ -137,13 +139,43 @@ static int request_frame(AVFilterLink *outlink)
>  AVFrame *buf;
>
>  av_fifo_generic_read(s->fifo, , sizeof(buf), NULL);
> -buf->pts = av_rescale_q(s->first_pts,
> ctx->inputs[0]->time_base,
> -outlink->time_base) + s->frames_out;
> +if (av_fifo_size(s->fifo)) {
> +buf->pts = av_rescale_q(s->first_pts,
> ctx->inputs[0]->time_base,
> +outlink->time_base) +
> s->frames_out;
>
> -if ((ret = ff_filter_frame(outlink, buf)) < 0)
> -return ret;
> +if ((ret = ff_filter_frame(outlink, buf)) < 0)
> +return ret;
>
> -s->frames_out++;
> +s->frames_out++;
> +} else {
> +/* This is the last frame, we may have to duplicate it to
> match
> + * the last frame duration */
> +int j;
> +int delta = av_rescale_q_rnd(ctx->inputs[0]->current_pts
> - s->first_pts,
> + ctx->inputs[0]->time_base,
> + outlink->time_base,
> s->rounding) - s->frames_out ;
> +if (delta > 0 ) {
> +for (j = 0; j < delta; j++) {
> +AVFrame *dup = av_frame_clone(buf);
> +
> +av_log(ctx, AV_LOG_DEBUG, "Duplicating frame.\n");
> +dup->pts = av_rescale_q(s->first_pts,
> ctx->inputs[0]->time_base,
> +outlink->time_base) +
> s->frames_out;
> +
> +if ((ret = ff_filter_frame(outlink, dup)) < 0)
> +return ret;
> +
> +s->frames_out++;
> +}
> +} else {
> +buf->pts = av_rescale_q(s->first_pts,
> ctx->inputs[0]->time_base,
> +outlink->time_base) +
> s->frames_out;
> +
> +if ((ret = ff_filter_frame(outlink, buf)) < 0)
> +return ret;
> +s->frames_out++;
> +}
> +}
>  }
>  return 0;
>  }
>

Your patch only resolves wrong framerate conversion durations for output
fps > input fps. I think the EOF misbehaviour should be solved for any
conversion.
I wrote a similar patch some months ago:
http://ffmpeg.org/pipermail/ffmpeg-devel/2017-March/209085.html
It was rejected because of the use of pkt_duration, like your first patch,
and the dupliction of non-trivial code. Also it used average frame duration
when pkt_duration was not available.
Now, after the patches Nicolas wrote and pushed the last weeks, it should
be possible to find a general solution.
Check the example at ticket #2674 for testing several framerate conversions.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avfilter/interlace: prevent over-sharpening with the complex low-pass filter

[Thomas Mundt]

2017-09-01 1:55 GMT+02:00 Thomas Mundt <tmund...@gmail.com>:

> 2017-09-01 1:22 GMT+02:00 Michael Niedermayer <mich...@niedermayer.cc>:
>
>> On Fri, Sep 01, 2017 at 01:18:11AM +0200, Michael Niedermayer wrote:
>> > On Thu, Aug 31, 2017 at 10:40:12PM +0200, Thomas Mundt wrote:
>> > > 2017-08-31 21:42 GMT+02:00 Michael Niedermayer <mich...@niedermayer.cc
>> >:
>> > >
>> > > > On Wed, Aug 30, 2017 at 03:54:08AM +0200, Thomas Mundt wrote:
>> > > > > Hi,
>> > > > >
>> > > > > we did a transcoding cascade test at work were over-sharpening
>> became
>> > > > > visible with the complex low-pass filter. This patch rectifies the
>> > > > > behaviour.
>> > > > >
>> > > > > Please comment...
>> > > >
>> > > > did you perform subjective and or objective tests ?
>> > > >
>> > > > objective being some metric like PSNR vs correctly sampled data
>> > > > subjective being double blind tests with humans about which they
>> prefer
>> > > >
>> > >
>> > > The tests have been subjective with a team of video engineers and
>> > > technicians with several test files.
>> > >
>> > > I did a quick SSIM/PSNR check with the first generation of an HD->SD
>> file
>> > > as a reference against the 6th generation.
>> >
>> > if its better then iam fine with it. No more comments from me
>>
>> ahh, forgot, you may want tp add the tests you did and their results
>> to the commit message
>
>
> Sure, new patch attached.
>

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

Re: [FFmpeg-devel] [PATCH] avfilter/interlace: prevent over-sharpening with the complex low-pass filter

[Thomas Mundt]

2017-09-01 1:22 GMT+02:00 Michael Niedermayer <mich...@niedermayer.cc>:

> On Fri, Sep 01, 2017 at 01:18:11AM +0200, Michael Niedermayer wrote:
> > On Thu, Aug 31, 2017 at 10:40:12PM +0200, Thomas Mundt wrote:
> > > 2017-08-31 21:42 GMT+02:00 Michael Niedermayer <mich...@niedermayer.cc
> >:
> > >
> > > > On Wed, Aug 30, 2017 at 03:54:08AM +0200, Thomas Mundt wrote:
> > > > > Hi,
> > > > >
> > > > > we did a transcoding cascade test at work were over-sharpening
> became
> > > > > visible with the complex low-pass filter. This patch rectifies the
> > > > > behaviour.
> > > > >
> > > > > Please comment...
> > > >
> > > > did you perform subjective and or objective tests ?
> > > >
> > > > objective being some metric like PSNR vs correctly sampled data
> > > > subjective being double blind tests with humans about which they
> prefer
> > > >
> > >
> > > The tests have been subjective with a team of video engineers and
> > > technicians with several test files.
> > >
> > > I did a quick SSIM/PSNR check with the first generation of an HD->SD
> file
> > > as a reference against the 6th generation.
> >
> > if its better then iam fine with it. No more comments from me
>
> ahh, forgot, you may want tp add the tests you did and their results
> to the commit message


Sure, new patch attached.


0001-avfilter-interlace-prevent-over-sharpening-with-the-.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avfilter/interlace: prevent over-sharpening with the complex low-pass filter

[Thomas Mundt]

2017-08-31 21:42 GMT+02:00 Michael Niedermayer <mich...@niedermayer.cc>:

> On Wed, Aug 30, 2017 at 03:54:08AM +0200, Thomas Mundt wrote:
> > Hi,
> >
> > we did a transcoding cascade test at work were over-sharpening became
> > visible with the complex low-pass filter. This patch rectifies the
> > behaviour.
> >
> > Please comment...
>
> did you perform subjective and or objective tests ?
>
> objective being some metric like PSNR vs correctly sampled data
> subjective being double blind tests with humans about which they prefer
>

The tests have been subjective with a team of video engineers and
technicians with several test files.

I did a quick SSIM/PSNR check with the first generation of an HD->SD file
as a reference against the 6th generation.
ffmpeg -i test.mxf -i ref.mxf -lavfi  "ssim;[0:v][1:v]psnr" -f null -
2>test.txt
Results without the patch:
[Parsed_ssim_0 @ 041bef00] SSIM Y:0.956508 (13.615881) U:0.991601
(20.757750) V:0.993004 (21.551382) All:0.974405 (15.918463)
[Parsed_psnr_1 @ 03fc8440] PSNR y:31.838009 u:48.424280 v:48.962711
average:34.759466 min:31.699297 max:40.857847
Results with the patch:
[Parsed_ssim_0 @ 0424ed00] SSIM Y:0.970051 (15.236232) U:0.991883
(20.905857) V:0.993174 (21.658049) All:0.981290 (17.279202)
[Parsed_psnr_1 @ 0424f780] PSNR y:34.412108 u:48.504454 v:48.969496
average:37.264644 min:34.310637 max:42.373392
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] avfilter/interlace: prevent over-sharpening with the complex low-pass filter

[Thomas Mundt]

Hi,

we did a transcoding cascade test at work were over-sharpening became
visible with the complex low-pass filter. This patch rectifies the
behaviour.

Please comment...


0001-avfilter-interlace-prevent-over-sharpening-with-the-.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v3] avfilter/vf_fps: fix duration

[Thomas Mundt]

2017-06-15 21:23 GMT+02:00 Nicolas George <geo...@nsup.org>:

> Le septidi 27 prairial, an CCXXV, Thomas Mundt a écrit :
> > Hmm, before rewriting and sending this patch I asked if it would have a
> > chance to be pushed just to fix the ticket which is open for a very long
> > time. Your answer gave me the assumtion that you´re okay with it.
> > I thought your only concern was the not allowed use of pkt_duration.
>
> I am ok in principle with a patch that uses the frame rate instead of
> the correct final timestamp. But not any such patch.
>
> I am not ok with a patch that makes the code more complex. I will at
> some point start again working on this, and any extra code complexity
> will make my life harder.
>
> In particular, I am never ok with a patch that copy-pastes and
> duplicates a non-trivial block of code.
>
> In fact, even if your patch was perfect in its logic, i.e. used the
> correct final timestamp, I would reject it based on the code complexity
> and duplication.
>
> As I said : the moment you used the "copy" feature of your editor on a
> non-trivial block of code, you should have stopped and taken a step back
> to look at the big picture.
>

I´m afraid the big picture might be to big for me.
The only thing I see that could be factored out is the delta for loop. And
even this would need much more investigation and testing form my side.
Unfortunately my time is too limited atm.
I think I understand your position, so I hope one day you will find the
time for the right fix.

Regards,
Thomas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v3] avfilter/vf_fps: fix duration

[Thomas Mundt]

2017-06-15 20:00 GMT+02:00 Nicolas George <geo...@nsup.org>:

> Le quintidi 25 prairial, an CCXXV, Thomas Mundt a écrit :
> > Patch attached. This fixes ticket #2674. I inserted a FIXME message as a
> > reminder.
> > Please comment.
>
> I am sorry to say I do not like it. The timestamp computation code in
> vf_fps is already quite complex, and this patch is making it more
> complex, introducing frames_in_proc which should not be needed just to
> fix the last timestamp, and obviously the EOF handling duplicates the
> filter_frame() logic.
>
> Hmm, before rewriting and sending this patch I asked if it would have a
chance to be pushed just to fix the ticket which is open for a very long
time. Your answer gave me the assumtion that you´re okay with it.
I thought your only concern was the not allowed use of pkt_duration.


> I think the way forward for this filter is to rewrite the core logic
> using the activate() design. It should be much simpler since the
> framework already handles a FIFO. If you are interested in it, you
> probably will need to rebase push this series:
>
> https://ffmpeg.org/pipermail/ffmpeg-devel/2017-April/209678.html
>
> and use the attached patch.
>
> Well, my problem is that I´m not deep enough in ffmpeg programming to
understand the interrelations of timestamp handling and unfortunately I
don´t have the time to figure it out.
Working with patches that I don´t fully understand doesn´t make any sense.
My intention was a fix within the filter to close the ticket. Just to
bridge the time until a proper fix is made.

Regards,
Thomas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v3] avfilter/vf_fps: fix duration

[Thomas Mundt]

2017-06-13 15:04 GMT+02:00 Thomas Mundt <tmund...@gmail.com>:

> 2017-06-13 15:00 GMT+02:00 Nicolas George <geo...@nsup.org>:
>
>> Le quintidi 25 prairial, an CCXXV, Thomas Mundt a écrit :
>> > Live with the open ticket or with the modified patch?
>>
>> Either, actually, but I meant the modified patch.
>>
>
> Okay, I´ll write the patch then and send it soon.
>

Patch attached. This fixes ticket #2674. I inserted a FIXME message as a
reminder.
Please comment.

Regards,
Thomas


0001-avfilter-vf_fps-fix-duration.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v3] avfilter/vf_fps: fix duration

[Thomas Mundt]

2017-06-13 15:00 GMT+02:00 Nicolas George <geo...@nsup.org>:

> Le quintidi 25 prairial, an CCXXV, Thomas Mundt a écrit :
> > Live with the open ticket or with the modified patch?
>
> Either, actually, but I meant the modified patch.
>

Okay, I´ll write the patch then and send it soon.

Thanks and regards,
Thomas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v3] avfilter/vf_fps: fix duration

[Thomas Mundt]

2017-06-13 14:46 GMT+02:00 Nicolas George :

> Le quintidi 25 prairial, an CCXXV, Thoms Mundt a écrit :
> > Since I dont see any solution or wip for this, I could modify my patch
> and
> > remove the use of pkt_duration. This would only work for constant frame
> rate
> > input, but fixes ticket #2674 which is open for 4 years now.
>
> I can live with that.
>
> Regards,
>

Live with the open ticket or with the modified patch?

Regards,
Thomas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v3 2/2] avfilter/interlace: add complex vertical low-pass filter

[Thomas Mundt]

2017-05-02 19:14 GMT+02:00 James Almer <jamr...@gmail.com>:

> On 5/2/2017 1:49 PM, Paul B Mahol wrote:
> > On 5/2/17, Thomas Mundt <tmund...@gmail.com> wrote:
> >> 2017-04-29 18:15 GMT+02:00 Thomas Mundt <tmund...@gmail.com>:
> >>
> >>> 2017-04-20 23:54 GMT+02:00 Thomas Mundt <tmund...@gmail.com>:
> >>>
> >>>> Patch attached...
> >>>>
> >>>> Ping
> >>>
> >>
> >> Ping
> >> ___
> >> ffmpeg-devel mailing list
> >> ffmpeg-devel@ffmpeg.org
> >> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> >>
> >
> > Michael? Gonna apply this?
>
> Applied it since i reviewed it in part.
>

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

Re: [FFmpeg-devel] [PATCH v3 2/2] avfilter/interlace: add complex vertical low-pass filter

[Thomas Mundt]

2017-04-29 18:15 GMT+02:00 Thomas Mundt <tmund...@gmail.com>:

> 2017-04-20 23:54 GMT+02:00 Thomas Mundt <tmund...@gmail.com>:
>
>> Patch attached...
>>
>> Ping
>

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

Re: [FFmpeg-devel] [PATCH v3 2/2] avfilter/interlace: add complex vertical low-pass filter

[Thomas Mundt]

2017-04-20 23:54 GMT+02:00 Thomas Mundt <tmund...@gmail.com>:

> Patch attached...
>
> Ping
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH v3 1/2] avfilter/interlace: change lowpass_line function prototype

[Thomas Mundt]

Hi,

this patch set
1) changes the lowpass_line function prototype in vf_interlace and
vf_tinterlace as suggested by James Almer.
2) adds a complex (-1 2 6 2 -1) vertical low-pass filter to
vf_interlace and vf_tinterlace.
This one slightly less reduces interlace 'twitter' but better retains
detail and subjective sharpness impression compared to the linear (1 2
1) filter.
The (-1 2 6 2 -1) filter gave best results tested with several CRT,
TFT and OLED monitors, hardware and software deinterlacers.

Patch attached...


0001-avfilter-interlace-change-lowpass_line-function-prot.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel