Re: [FFmpeg-devel] [PATCH] avfilter/vf_bwdif: consider chroma subsampling when enforcing minimum dimensions
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 v2 1/3] avfilter/vf_bwdif: consider chroma subsampling when enforcing minimum dimensions
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(&s->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 v3 1/3] avfilter/vf_bwdif: consider chroma subsampling when enforcing minimum dimensions
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(&s->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] avformat/mxfenc: support XAVC long gop
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] avformat/mxfenc: support XAVC long gop
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 2/2] avformat/mxfenc: support XAVC long gop
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
Re: [FFmpeg-devel] [PATCH 2/2] avformat/mxfenc: support XAVC long gop
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] avformat/mxfenc: support XAVC long gop
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] avformat/mxfenc: support XAVC long gop
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, &rbsp_size, 0);
> +if (!rbsp_buf)
> +return NULL;
> +
> +ret = init_get_bits8(&gb, rbsp_buf, rbsp_size);
> +if (ret < 0)
> +goto end;
> +
> +sps = av_mallocz(sizeof(*sps));
> +if (!sps)
> +goto end;
> +
> +sps->profile_idc = get_bits(&gb, 8);
> +sps->constraint_set_flags |= get_bits1(&gb) << 0; //
> constraint_set0_flag
> +sps->constraint_set_flags |= get_bits1(&gb) << 1; //
> constraint_set1_flag
> +sps->constraint_set_flags |= get_bits1(&gb) << 2; //
> constraint_set2_flag
> +sps->constraint_set_flags |= get_bits1(&gb) << 3; //
> constraint_set3_flag
> +sps->constraint_set_flags |= get_bits1(&gb) << 4; //
> constraint_set4_flag
> +sps->constraint_set_flags |= get_bits1(&gb) << 5; //
> constraint_set5_flag
> +skip_bits(&gb, 2); // reserved_zero_2bits
> +sps->level_idc = get_bits(&gb, 8);
> +sps->id = get_ue_golomb(&gb);
> +
> +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 == 12
Re: [FFmpeg-devel] [PATCH] avformat/mxfenc: support XAVC long gop
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, &rbsp_size, 0);
> +if (!rbsp_buf)
> +return NULL;
> +
> +ret = init_get_bits8(&gb, rbsp_buf, rbsp_size);
> +if (ret < 0)
> +goto end;
> +
> +sps = av_mallocz(sizeof(*sps));
> +if (!sps)
> +goto end;
> +
> +sps->profile_idc = get_bits(&gb, 8);
> +sps->constraint_set_flags |= get_bits1(&gb) << 0; //
> constraint_set0_flag
> +sps->constraint_set_flags |= get_bits1(&gb) << 1; //
> constraint_set1_flag
> +sps->constraint_set_flags |= get_bits1(&gb) << 2; //
> constraint_set2_flag
> +sps->constraint_set_flags |= get_bits1(&gb) << 3; //
> constraint_set3_flag
> +sps->constraint_set_flags |= get_bits1(&gb) << 4; //
> constraint_set4_flag
> +sps->constraint_set_flags |= get_bits1(&gb) << 5; //
> constraint_set5_flag
> +skip_bits(&gb, 2); // reserved_zero_2bits
> +sps->level_idc = get_bits(&gb, 8);
> +sps->id = get_ue_golomb(&gb);
> +
> +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 == 12
[FFmpeg-devel] [PATCH] libavformat/mxfenc: Allow more bitrates for NTSC IMX50
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] libavformat/mxfenc: Allow more bitrates for NTSC IMX50
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".
Re: [FFmpeg-devel] [PATCH] libavformat/mxfenc: Allow more bitrates for NTSC IMX50
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
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".
[FFmpeg-devel] [PATCH] avfilter/vf_interlace: fix numerical options
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] avfilter/vf_interlace: fix numerical options
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
Re: [FFmpeg-devel] [PATCH] avfilter/vf_interlace: fix numerical options
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
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
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 1/2] avfilter/yadif_common: Add field type tracking to help bwdif
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 0/2] Update vf_bwdif to use yadif_common v2
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] avfilter/vf_bwdif: fix heap-buffer overflow
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 v2 1/2] avfilter/interlace: change lowpass_line function
>>Thomas Mundt schrieb am Mo, 13.3.2017: > 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. > Ping ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avfilter/vf_fps: fix duration
Hi, attached patch will fix ticket #2674. It makes the fps filter duplicate or drop the last frame depending on the input and output frame rates. Tested with examples from ticket 2674 and other files at various frame rates. 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] avfilter/vf_fps: fix duration
>>Michael Niedermayer schrieb am Mi, 22.3.2017: >>>On Tue, Mar 21, 2017 at 11:25:21PM +0000, Thomas Mundt wrote: >> Hi, >> >> attached patch will fix ticket #2674. >> It makes the fps filter duplicate or drop the last frame depending on the >> input and output frame rates. >> Tested with examples from ticket 2674 and other files at various frame rates. >> >> Regards, >> Thomas > >> vf_fps.c | 23 ++- >> 1 file changed, 18 insertions(+), 5 deletions(-) >> 01d220968700e58b1bd772fbf63dee55d29955f6 >> 0001-avfilter-vf_fps-fix-duration.patch >> From 6724eb3dae7b491d5bac3903cf4b7dc4ff037e6c Mon Sep 17 00:00:00 2001 >> From: Thomas Mundt >> Date: Wed, 22 Mar 2017 00:14:53 +0100 >> Subject: [PATCH] avfilter/vf_fps: fix duration >> >> Fix Ticket #2674 >> This makes the fps filter duplicate or drop the last frame depending on the >> input and output frame rates. Tested with examples from ticket 2674 and >> other files at various frame rates. >> >> Signed-off-by: Thomas Mundt >> --- >> libavfilter/vf_fps.c | 23 ++- >> 1 file changed, 18 insertions(+), 5 deletions(-) > > breaks fate > --- ./tests/ref/fate/m4v-cfr2017-03-20 19:25:54.157895388 +0100 > +++ tests/data/fate/m4v-cfr 2017-03-22 04:06:23.690852041 +0100 > @@ -44,4 +44,3 @@ > 0, 38, 38,1, 115200, 0xf30825d5 > 0, 39, 39,1, 115200, 0xe3c944a1 > 0, 40, 40,1, 115200, 0x8fec4420 > -0, 41, 41,1, 115200, 0x9381fdab > Test m4v-cfr failed. Look at tests/data/fate/m4v-cfr.err for details. > make: *** [fate-m4v-cfr] Error 1 > make: *** Waiting for unfinished jobs > New Patch attached... 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
[FFmpeg-devel] [PATCH v2] avfilter/vf_fps: fix duration
Hi, after checking the fate sample and further testing I noticed that the stated framerate is not always correct and can lead to wrong results. I didn´t find one single method to make it work correct in any case, so I added a fallback. av_frame_get_pkt_duration works for most files. Otherwise the average of the earlier pts steps is used to calculate the number of the final frame. Please comment 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
[FFmpeg-devel] [PATCH v3] avfilter/vf_fps: fix duration
Hi, attached patch will fix ticket #2674. Tested with examples from ticket 2674 and other files at various frame rates. v2: Use av_frame_get_pkt_duration to calculate count of duplication of last frame. Use average of the earlier pts steps when av_frame_get_pkt_duration is not set. v3: Write at least one output frame when start_time is zero or not set. Also changed broken filter-fps-r fate ref. I missed that in v2. Sorry! Please comment 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 v2 1/2] avfilter/interlace: change lowpass_line function
>>Thomas Mundt schrieb am Di, 21.3.2017: >>>Thomas Mundt schrieb am Mo, 13.3.2017: >> 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. >> > Ping > Ping, anybody? ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v2 2/2] avfilter/interlace: add complex vertical low-pass filter
>>Lou Logan schrieb am Do, 30.3.2017: > On Mon, 13 Mar 2017 16:23:46 + (UTC) > Thomas Mundt wrote: > > [...] >> index 09ca4d3..0b5b858 100644 >> --- a/libavfilter/vf_tinterlace.c >> +++ b/libavfilter/vf_tinterlace.c > [...] >> +static void lowpass_line_complex_c(uint8_t *dstp, ptrdiff_t width, const >> uint8_t *srcp, >> + ptrdiff_t mref, ptrdiff_t pref) > > Trailing whitespace should be avoided. It prevents the patch from being > applied. Oh, didn´t notice. Thanks. New patch set attached. 0001-avfilter-interlace-change-lowpass_line-function-prot.patch Description: Binary data 0002-avfilter-interlace-add-complex-vertical-low-pass-fil.patch Description: Binary data ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH v3] avfilter/vf_fps: fix duration
>>>Thomas Mundt schrieb am Fr, 24.3.2017: > Hi, > > > attached patch will fix ticket #2674. > Tested with examples from ticket 2674 and other files at various frame rates. > > v2: Use av_frame_get_pkt_duration to calculate count of duplication of last > frame. > Use average of the earlier pts steps when av_frame_get_pkt_duration is not > set. > v3: Write at least one output frame when start_time is zero or not set. > Also changed broken filter-fps-r fate ref. I missed that in v2. Sorry! > > Please comment Ping ___ 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 schrieb am Fr, 24.3.2017: > Hi, > > > attached patch will fix ticket #2674. > Tested with examples from ticket 2674 and other files at various frame rates. > > v2: Use av_frame_get_pkt_duration to calculate count of duplication of last > frame. > Use average of the earlier pts steps when av_frame_get_pkt_duration is not > set. > v3: Write at least one output frame when start_time is zero or not set. > Also changed broken filter-fps-r fate ref. I missed that in v2. Sorry! > > Please comment Ping ___ 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&In-Reply-To=<98109900.4785518.1490351969...@mail.yahoo.com>
>>>Thomas Mundt schrieb am Fr, 24.3.2017: > Hi, > > > attached patch will fix ticket #2674. > Tested with examples from ticket 2674 and other files at various frame rates. > > v2: Use av_frame_get_pkt_duration to calculate count of duplication of last > frame. > Use average of the earlier pts steps when av_frame_get_pkt_duration is not > set. > v3: Write at least one output frame when start_time is zero or not set. > Also changed broken filter-fps-r fate ref. I missed that in v2. Sorry! > > Please comment Ping ___ 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
>>>Nicolas George schrieb am Sa, 1.4.2017: > Le quartidi 4 germinal, an CCXXV, Thomas Mundt a écrit : >> v2: Use av_frame_get_pkt_duration to calculate count of duplication of last >> frame. >> Use average of the earlier pts steps when av_frame_get_pkt_duration is not >> set. > > Sorry for missing it earlier. > > pkt_duration is not used by lavfi. The duration of the last frame is > carried by link->current_pts after the status has been received. I found the use of this function in f_loop.c, so I thought it´s ok. link->current_pts always returns the pts until the current (last) frame. I can calculate its duration for cfr video, but not for vfr. I need the pts until the virtual next frame. At which point in the code can I get it? > Replied to the patch itself. For some reason your mail is not connected > to it. Yes, something went wrong with my mail in the mailing list. I wrote it as a new mail. But later, when I looked at it in the mail archives, it became a reply at the end of another thread. Yesterday I sent my ping as reply to my original mail, but it didn´t apear at the mailing list for hours. I thought that something went wrong and sent another mail by copy/pasting the re: subject from the mail archives. This also didn´t appear for more than one hour. So finally I sent a new mail which immediately appeared on the list. Now they are all in the list. Maybe, beside working on patches, I should work on my patience :-/ Sorry for the spam! ___ 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
>>>Nicolas George schrieb am So, 2.4.2017: >>Le tridi 13 germinal, an CCXXV, Thomas Mundt a écrit : >... >> link->current_pts always returns the pts until the current (last) frame. >> I can calculate its duration for cfr video, but not for vfr. I need the pts >> until the virtual next frame. >> At which point in the code can I get it? > > link->current_pts is updated when request_frame() returns EOF. But to > make it work, it would be necessary that the application injects the > timestamp when marking EOF, which is not yet done, but hopefully I will > have time to work on it in the next two weeks. > > But it is the correct way of doing things. Using the duration has too > many drawbacks. OK, I´ll wait and use my patch locally meanwhile. Will you also fix the ticket or shall I make a new patch then? 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
>>Nicolas George schrieb am So, 2.4.2017: >> Will you also fix the ticket or shall I make a new patch then? > > I do not understand what you mean. So I think I misunderstood. Sorry, please ignore that sentence. > And maybe you should find a mail user agent that works and does not > break threads. This yahoo thingie seems to be completely bogus. Yes, I will switch to gmail... 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
>>>Nicolas George schrieb am So, 2.4.2017: > Fortunately, you do not need to change your e-mail provider and address, > you only need to change your mail software: just choose and install a > real and good mail client instead of relying on webmails. You will gain > a lot in comfort; and if you configure it correctly you can still access > the webmail when needed. My problem is, that working on patches is partially hobby and partially needed for work. I´m working at different places with different computers used by many people. I´m not allowed to install any software. Using my smartphone is not always possible and wanted. I´ll try to find a portable solution that I can also use at home. Regards, Thomas ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v2 2/2] avfilter/interlace: add complex vertical low-pass filter
>>>Thomas Mundt schrieb am Do, 30.3.2017: >>>Lou Logan schrieb am Do, 30.3.2017: >> On Mon, 13 Mar 2017 16:23:46 +0000 (UTC) >> Thomas Mundt wrote: >> >> [...] >>> index 09ca4d3..0b5b858 100644 >>> --- a/libavfilter/vf_tinterlace.c >>> +++ b/libavfilter/vf_tinterlace.c >> [...] >>> +static void lowpass_line_complex_c(uint8_t *dstp, ptrdiff_t width, const >>> uint8_t *srcp, >>> + ptrdiff_t mref, ptrdiff_t pref) >> >> Trailing whitespace should be avoided. It prevents the patch from being >> applied. > > Oh, didn´t notice. Thanks. > New patch set attached. Ping ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v2 2/2] avfilter/interlace: add complex vertical low-pass filter
>>>Thomas Mundt schrieb am Mi, 5.4.2017: >>>>Thomas Mundt schrieb am Do, 30.3.2017: >>>>Lou Logan schrieb am Do, 30.3.2017: >>> On Mon, 13 Mar 2017 16:23:46 + (UTC) >>> Thomas Mundt wrote: >>> >>> [...] >>>> index 09ca4d3..0b5b858 100644 >>>> --- a/libavfilter/vf_tinterlace.c >>>> +++ b/libavfilter/vf_tinterlace.c >>> [...] >>>> +static void lowpass_line_complex_c(uint8_t *dstp, ptrdiff_t width, const >>>> uint8_t *srcp, >>>> + ptrdiff_t mref, ptrdiff_t pref) >>>> >>> >>> Trailing whitespace should be avoided. It prevents the patch from being >>> applied. >> >> Oh, didn´t notice. Thanks. >> New patch set attached. > > Ping Ping ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v2 2/2] avfilter/interlace: add complex vertical low-pass filter
>>>Michael Niedermayer schrieb am Mi, 12.4.2017: On Thu, Mar 30, 2017 at 12:21:58AM +0000, Thomas Mundt wrote: >> >>Lou Logan schrieb am Do, 30.3.2017: >> > On Mon, 13 Mar 2017 16:23:46 + (UTC) >> > Thomas Mundt wrote: >> > >> > [...] >> >> index 09ca4d3..0b5b858 100644 >> >> --- a/libavfilter/vf_tinterlace.c >> >> +++ b/libavfilter/vf_tinterlace.c >> > [...] >> >> +static void lowpass_line_complex_c(uint8_t *dstp, ptrdiff_t width, const >> >> uint8_t *srcp, >> >> + ptrdiff_t mref, ptrdiff_t pref) >> >> >> > >> > Trailing whitespace should be avoided. It prevents the patch from being >> > applied. >> >> Oh, didn´t notice. Thanks. >> New patch set attached. > > [...] >> --- a/libavfilter/x86/vf_interlace.asm >> +++ b/libavfilter/x86/vf_interlace.asm >> @@ -28,33 +28,28 @@ SECTION_RODATA >> SECTION .text >> >> %macro LOWPASS_LINE 0 >> -cglobal lowpass_line, 5, 5, 7 >> -add r0, r1 >> -add r2, r1 [...] >> -add r1, 2*mmsize >> -jl .loop >> +add dstq, 2*mmsize >> +add srcq, 2*mmsize >> +sub hd, 2*mmsize >> +jg .loop > > this increases the number of instructions in the inner loop by 2 James Almer suggested to change the function prototype. Which was easy in c, but for simd this is the best I can do. I asked for help a month ago but get no reply. Can you tell me how to avoid this? >also can you add a fate test for the -1 2 6 2-1 filter ? Sure. I never wrote a fate test and I´m off for a couple of days, so this could take some time. Can you give me a hint or an example? Regards, Thomas ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v2 2/2] avfilter/interlace: add complex vertical low-pass filter
>>>James Almer schrieb am Do, 13.4.2017: >>>>On 4/12/2017 9:39 PM, Thomas Mundt wrote: >> >> James Almer suggested to change the function prototype. Which was easy in c, >> but for simd this is the best I can do. > > I didn't check, but I think the reason i told you to change the prototype here > was to share the function pointer with lowpass_line_complex, so you can do > something like > > if (tinterlace->flags & TINTERLACE_FLAG_VLPF) > tinterlace->lowpass_line = lowpass_line_c; > else if (tinterlace->flags & TINTERLACE_FLAG_CVLPF) > tinterlace->lowpass_line = lowpass_line_complex_c; > > instead of adding a new one to InterlaceContext and TInterlaceContext. > Otherwise you wouldn't really gain much changing the prototype for linear > here. Okay, I will change that when I´m back from vacation in a week. >> I asked for help a month ago but get no reply. Can you tell me how to avoid >> this? > > Yes, sorry, i kinda lost track of this since for some reason your emails start > a new thread each instead of showing up as a reply. Yes, the yahoo web cient is buggy. I will change this also. > You just need to turn mref and pref into the equivalent of the old srcp_above > and srcp_below pointers, like so: > > diff --git a/libavfilter/x86/vf_interlace.asm > b/libavfilter/x86/vf_interlace.asm > index f70c700965..8a0dd3bdea 100644 > --- a/libavfilter/x86/vf_interlace.asm > +++ b/libavfilter/x86/vf_interlace.asm > @@ -28,32 +28,32 @@ SECTION_RODATA > SECTION .text > > %macro LOWPASS_LINE 0 > -cglobal lowpass_line, 5, 5, 7 > -add r0, r1 > -add r2, r1 > -add r3, r1 > -add r4, r1 > -neg r1 > +cglobal lowpass_line, 5, 5, 7, dst, h, src, mref, pref > +add dstq, hq > +add srcq, hq > +add mrefq, srcq > +add prefq, srcq > +neg hq Thanks a lot! Regards, Thomas ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH v3 2/2] avfilter/interlace: add complex vertical low-pass filter
Patch attached... 0002-avfilter-interlace-add-complex-vertical-low-pass-fil.patch Description: Binary data ___ 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
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
Re: [FFmpeg-devel] [PATCH v3 2/2] avfilter/interlace: add complex vertical low-pass filter
2017-04-20 23:54 GMT+02:00 Thomas Mundt : > Patch attached... > > 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
2017-04-29 18:15 GMT+02:00 Thomas Mundt : > 2017-04-20 23:54 GMT+02:00 Thomas Mundt : > >> 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
2017-05-02 19:14 GMT+02:00 James Almer : > On 5/2/2017 1:49 PM, Paul B Mahol wrote: > > On 5/2/17, Thomas Mundt wrote: > >> 2017-04-29 18:15 GMT+02:00 Thomas Mundt : > >> > >>> 2017-04-20 23:54 GMT+02:00 Thomas Mundt : > >>> > >>>> 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] avfilter/vf_fps: fix duration
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] avfilter/vf_fps: fix duration
2017-06-13 15:00 GMT+02:00 Nicolas George : > 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
2017-06-13 15:04 GMT+02:00 Thomas Mundt : > 2017-06-13 15:00 GMT+02:00 Nicolas George : > >> 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
2017-06-15 20:00 GMT+02:00 Nicolas George : > 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
2017-06-15 21:23 GMT+02:00 Nicolas George : > 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] avfilter/x86/vf_interlace : fix crash if unaligned data (ticket 6491)
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] avfilter/x86/vf_interlace : fix crash in low_pass_complex
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)
2017-12-14 21:33 GMT+01:00 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. > 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/vf_interlace : add checkasm for lowpass_line and AVX2 version
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/vf_interlace and vf_tinterlace : remove avx version
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
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 : add checkasm for lowpass_line and AVX2 version
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] [PATCH] avfilter/interlace: prevent over-sharpening with the complex low-pass filter
2017-08-31 21:42 GMT+02:00 Michael Niedermayer : > 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
Re: [FFmpeg-devel] [PATCH] avfilter/interlace: prevent over-sharpening with the complex low-pass filter
2017-09-01 1:22 GMT+02:00 Michael Niedermayer : > 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 >: > > > > > > > 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
2017-09-01 1:55 GMT+02:00 Thomas Mundt : > 2017-09-01 1:22 GMT+02:00 Michael Niedermayer : > >> 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 > >: >> > > >> > > > 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] vf_fps: when reading EOF, using current_pts to duplicate the last frame if needed.
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, &buf, 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] vf_fps: when reading EOF, using current_pts to duplicate the last frame if needed.
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, &buf, 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.
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, &buf, 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)
> +ret
Re: [FFmpeg-devel] [PATCH] avfilter/interlace: prevent over-sharpening with the complex low-pass filter
2017-09-06 22:15 GMT+02:00 Thomas Mundt : > 2017-09-01 1:55 GMT+02:00 Thomas Mundt : > >> 2017-09-01 1:22 GMT+02:00 Michael Niedermayer : >> >>> 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 >>> : >>> > > >>> > > > 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
[FFmpeg-devel] [PATCH 0/3] avfilter/interlace: add support for 10 and 12 bit
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
[FFmpeg-devel] [PATCH 2/3] avfilter/tinterlace: use drawutils for pad mode
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 3/3] avfilter/interlace: add support for 10 and 12 bit
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 1/3] avfilter/interlace: simplify code
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
Re: [FFmpeg-devel] [PATCH] avfilter/interlace: prevent over-sharpening with the complex low-pass filter
2017-09-13 23:35 GMT+02:00 Thomas Mundt : > 2017-09-06 22:15 GMT+02:00 Thomas Mundt : > >> 2017-09-01 1:55 GMT+02:00 Thomas Mundt : >> >>> 2017-09-01 1:22 GMT+02:00 Michael Niedermayer : >>> >>>> 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 >>>> : >>>> > > >>>> > > > 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
Re: [FFmpeg-devel] [PATCH] avfilter/interlace: prevent over-sharpening with the complex low-pass filter
2017-09-15 22:26 GMT+02:00 Michael Niedermayer : > 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 3/3] avfilter/interlace: add support for 10 and 12 bit
2017-09-15 22:15 GMT+02:00 Michael Niedermayer : > 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 > > > 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 > > > --- > > > 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
[FFmpeg-devel] [PATCH] MAINTAINERS: add myself for bwdif and (t)interlace
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
[FFmpeg-devel] [PATCH 2/3 v2] avfilter/tinterlace: use drawutils for pad mode
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 3/3 v2] avfilter/interlace: add support for 10 and 12 bit
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
Re: [FFmpeg-devel] [PATCH 3/3 v2] avfilter/interlace: add support for 10 and 12 bit
2017-09-19 4:09 GMT+02:00 James Almer :
> 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
> > 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
> > ---
> > 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,
> > + ptrdiff_t pref, int clip_max)
> > {
> > const uint8_t *srcp_above = s
Re: [FFmpeg-devel] [PATCH 3/3 v2] avfilter/interlace: add support for 10 and 12 bit
2017-09-19 17:53 GMT+02:00 James Almer :
> On 9/19/2017 5:02 AM, Thomas Mundt wrote:
> > 2017-09-19 4:09 GMT+02:00 James Almer :
> >
> >> 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
> >>> 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
> >>> ---
> >>> 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);
> >&g
[FFmpeg-devel] [PATCH] avfilter/interlace: rename two variables for consistency
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
2017-09-23 20:24 GMT+02:00 Michael Niedermayer :
> On Tue, Sep 19, 2017 at 10:35:30PM +0200, Thomas Mundt wrote:
> > 2017-09-19 17:53 GMT+02:00 James Almer :
> >
> > > On 9/19/2017 5:02 AM, Thomas Mundt wrote:
> > > > 2017-09-19 4:09 GMT+02:00 James Almer :
> > > >
> > > >> 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
> > > >>> 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
> > > >>> ---
> > > >>> 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 @@
> > > >>&
Re: [FFmpeg-devel] [PATCH] avfilter/interlace: rename two variables for consistency
2017-09-19 22:54 GMT+02:00 Thomas Mundt : > 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 5/5] ffmpeg: send EOF pts to filters.
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] lavfi/avfilter.c: Correct guess_status_pts to account for differing link timebases.
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] lavfi/avfilter.c: Correct guess_status_pts to account for differing link timebases.
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] ffmpeg.c: Fallback to duration_dts, when duration_pts can't be determined.
2017-10-10 3:27 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 | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c > index 6d64bc1043..5f373db847 100644 > --- a/fftools/ffmpeg.c > +++ b/fftools/ffmpeg.c > @@ -2665,6 +2665,9 @@ static int process_input_packet(InputStream *ist, > const AVPacket *pkt, int no_eo > ist->next_dts = AV_NOPTS_VALUE; > } > > +if (duration_pts == 0) > +duration_pts = duration_dts; > + > if (got_output) > ist->next_pts += av_rescale_q(duration_pts, > ist->st->time_base, AV_TIME_BASE_Q); > break; > duration_dts is already rescaled. Should be ist->next_pts += duration_dts when duration_pts == 0. 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.
2017-10-10 19:44 GMT+02:00 wm4 :
> On Tue, 10 Oct 2017 10:36:58 -0700
> Sasi Inguva wrote:
>
> > 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)
>
> So why can't duration_pts be 0?
>
Hmm, to my understanding that would be a frame with no duration. Virtually
an invisible frame.
Can you give an example?
___
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.
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] ffmpeg.c: Fallback to duration_dts, when duration_pts can't be determined.
Hi Michael,
2017-10-12 1:28 GMT+02:00 Michael Niedermayer :
> On Tue, Oct 10, 2017 at 10:26:13PM +0200, Thomas Mundt wrote:
> > 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.
>
> 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] R: [PATCH] MXF format fix for Sony Station compatibility
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] avfilter: add BobWeaver deinterlacing filter
>>> Paul B Mahol schrieb am Di, 16.2.2016:On 2/8/16, Thomas >>> Mundt wrote: >>>>> Hendrik Leppkes schrieb am Mo, 8.2.2016: >>> How does the speed compare to YADIF? >>> Or in other words, is it usable in real-time, or rather designed for >>> offline processing? >>> >> YADIF is quicker, because of its CPU optimizations. Without CPU >> optimizations BobWeaver is quicker. >> It should definitely be usable in real-time. > > Could you provide samples when this filters gives better output than > yadif/w3fdif ? Shure. Is there an intended place where I can upload them or is it free choice? Please note that the output is not better than yadif AND w3dif. But it will look like yadif when yadif is better than w3fdif and look like w3fdif when w3fdif is better than yadif. I´m at work atm, but will upload the samples tonight. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfilter: add BobWeaver deinterlacing filter
>>> Paul B Mahol schrieb am Di, 16.2.2016: >>>> On 2/8/16, Thomas Mundt wrote: >>>>> Hendrik Leppkes schrieb am Mo, 8.2.2016: >>> How does the speed compare to YADIF? >>> Or in other words, is it usable in real-time, or rather designed for >>> offline processing? >>> >> YADIF is quicker, because of its CPU optimizations. Without CPU >> optimizations BobWeaver is quicker. >> It should definitely be usable in real-time. > > Could you provide samples when this filters gives better output than > yadif/w3fdif ? I´ve uploaded some samples for comparison: http://free-vsts.com/files/bwdif_w3fdif_yadif.zip I used the same command for all competitors: ffmpeg -i xxx_orig.mp4 -vf DEINTERLACER -r 50 -aspect 16:9 -vcodec libx264 -crf 18 out.mp4 bwdif DEINTERLACER: bwdif yadif DEINTERLACER: yadif=1 w3fdif DEINTERLACER: w3fdif=filter=complex For comparison of moving interlaced scenes I´ve uploaded the sample parkjoy(pj). This is difficult for deinterlacers and doesn´t look very good with all competitors. Yadif makes kind of a watercolor effect. W3fdif is much closer to the original progressive parkjoy source file. BobWeaver is very close to w3fdif, but shows less artefacts especially in moving front trees. For comparison of still interlaced scenes I´ve uploaded the samples kiosk and bars. Here w3fdif shows jigging because of its absent still pixel detection. Yadif and BobWeaver are fine. With sample bars only BobWeaver shows the correct 3 white lines in the timecode. I don´t have original progressive versions of kiosk and bars, since this is broadcast content. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfilter: add BobWeaver deinterlacing filter
>>> Paul B Mahol schrieb am Mi, 17.2.2016: > If nobody plans to comment on code I will apply this soon. I´ve seen you applied it. Thanks. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avfilter/vf_bwdif: add x86 SIMD for 8bit
The attached patch is my first SIMD code. It is more than 3x faster, so optimisations work. But experienced programmers may find some more improvement. I´m not really happy with the extra mov instructions needed in x86_32 for mrefs3 and prefs3 because of the register limitations. I tried a lot, but this was the only way I made it work. Since bwdif is based on yadif, I stole parts of the SIMD code from there. Also for learning how it works. Maybe I should add Michael and Daniel to the licence? I will write SMID code for higher bitrates later, when this patch is approved. Please comment. 0001-vf_bwdif-add-x86-SIMD-for-8bit.patch Description: Binary data ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH v2] avfilter/vf_bwdif: add x86 SIMD
This new patch adds x86 SIMD support up to 12 bit.
Please comment.
Signed-off-by: Thomas Mundt
---
libavfilter/bwdif.h | 72 +++
libavfilter/vf_bwdif.c | 69 +++
libavfilter/x86/Makefile| 2 +
libavfilter/x86/vf_bwdif.asm| 266
libavfilter/x86/vf_bwdif_init.c | 78
5 files changed, 432 insertions(+), 55 deletions(-)
create mode 100644 libavfilter/bwdif.h
create mode 100644 libavfilter/x86/vf_bwdif.asm
create mode 100644 libavfilter/x86/vf_bwdif_init.c
diff --git a/libavfilter/bwdif.h b/libavfilter/bwdif.h
new file mode 100644
index 000..8b42c76
--- /dev/null
+++ b/libavfilter/bwdif.h
@@ -0,0 +1,72 @@
+/*
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#ifndef AVFILTER_BWDIF_H
+#define AVFILTER_BWDIF_H
+
+#include "libavutil/pixdesc.h"
+#include "avfilter.h"
+
+enum BWDIFMode {
+BWDIF_MODE_SEND_FRAME = 0, ///< send 1 frame for each frame
+BWDIF_MODE_SEND_FIELD = 1, ///< send 1 frame for each field
+};
+
+enum BWDIFParity {
+BWDIF_PARITY_TFF = 0, ///< top field first
+BWDIF_PARITY_BFF = 1, ///< bottom field first
+BWDIF_PARITY_AUTO = -1, ///< auto detection
+};
+
+enum BWDIFDeint {
+BWDIF_DEINT_ALL= 0, ///< deinterlace all frames
+BWDIF_DEINT_INTERLACED = 1, ///< only deinterlace frames marked as
interlaced
+};
+
+typedef struct BWDIFContext {
+const AVClass *class;
+
+int mode; ///< BWDIFMode
+int parity; ///< BWDIFParity
+int deint; ///< BWDIFDeint
+
+int frame_pending;
+
+AVFrame *cur;
+AVFrame *next;
+AVFrame *prev;
+AVFrame *out;
+
+void (*filter_intra)(void *dst1, void *cur1, int w, int prefs, int mrefs,
+ int prefs3, int mrefs3, int parity, int clip_max);
+void (*filter_line)(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 (*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);
+
+const AVPixFmtDescriptor *csp;
+int inter_field;
+int eof;
+} BWDIFContext;
+
+void ff_bwdif_init_x86(BWDIFContext *bwdif);
+
+#endif /* AVFILTER_BWDIF_H */
diff --git a/libavfilter/vf_bwdif.c b/libavfilter/vf_bwdif.c
index 7985054..d402aa4 100644
--- a/libavfilter/vf_bwdif.c
+++ b/libavfilter/vf_bwdif.c
@@ -37,6 +37,7 @@
#include "formats.h"
#include "internal.h"
#include "video.h"
+#include "bwdif.h"
/*
* Filter coefficients coef_lf and coef_hf taken from BBC PH-2071 (Weston 3
Field Deinterlacer).
@@ -48,51 +49,6 @@ static const uint16_t coef_lf[2] = { 4309, 213 };
static const uint16_t coef_hf[3] = { 5570, 3801, 1016 };
static const uint16_t coef_sp[2] = { 5077, 981 };
-enum BWDIFMode {
-BWDIF_MODE_SEND_FRAME = 0, ///< send 1 frame for each frame
-BWDIF_MODE_SEND_FIELD = 1, ///< send 1 frame for each field
-};
-
-enum BWDIFParity {
-BWDIF_PARITY_TFF = 0, ///< top field first
-BWDIF_PARITY_BFF = 1, ///< bottom field first
-BWDIF_PARITY_AUTO = -1, ///< auto detection
-};
-
-enum BWDIFDeint {
-BWDIF_DEINT_ALL= 0, ///< deinterlace all frames
-BWDIF_DEINT_INTERLACED = 1, ///< only deinterlace frames marked as
interlaced
-};
-
-typedef struct BWDIFContext {
-const AVClass *class;
-
-int mode; ///< BWDIFMode
-int parity; ///< BWDIFParity
-int deint; ///< BWDIFDeint
-
-int frame_pending;
-
-AVFrame *cur;
-AVFrame *next;
-AVFrame *prev;
-AVFrame *out;
-
-void (*filter_intra)(void *dst1, void *cur1, int w, int prefs, int mrefs,
- int prefs3, int mrefs3, int parity, int clip_max);
-void (*filter_line)(void *dst, void *prev, void *cur, void *next,
-int w, int prefs, int mrefs, int prefs2, int mrefs2,
-
Re: [FFmpeg-devel] [PATCH v2] avfilter/vf_bwdif: add x86 SIMD
>>> Thomas Mundt wrote: >> This new patch adds x86 SIMD support up to 12 bit. Please comment. > > Not much use I guess, but on sse2 8 bit content it tests OK = faster + > md5sum the same as without the patch. > > Are you considering going further with this? > > Being sharper than yadif/preserving weave is nice, but for some SD > (viewing scaled up) yadif wins on moving low angle diagonals, which end > up stepped. > > From memory when testing intel h/w deint it did a nice motion adaptive > deint of the same scene without steps. The possible difference being > that its "bob" > also did some sort of edge detection/interpolation. > We testet deinterlacers at work last year. Professional hard- and software and also ffmpeg. All my colleagues preferred w3fdif over yadif because it looks more homogeneous and reminds a little of the sharpness and visual impression of crt monitors. Yadif definitely better reproduces moving diagonals and stills, but harms the picture too much at details and slightly blurs it. So I tried to combine the best of both. I was successful with stills, but didn´t find a useful edge detection that helps more than it harms. There are some working edge detection models, but very complicated and speed was also very important. The most promising and fast method was comparing vertical and diagonal differences around and horizontal nearby the interpolated pixel. But I always found samples were it leads to heavy artefacts. Especially visible with our new oled monitors. The resulting bwdif was the best compromise between quality (of course subjective) and speed for general purpose content. This simd patch is faster than yadif. With the snooker sample yadif performs better mostly because there are not many details. But you can see yadif´s artefacts in the players face at the end. Also bwdif performs slightly better than w3fdif here. Hardware scalers these days seem to have mature deinterlacers. In our test Aja, Lynx and other professional scalers and also nvidia and intel gpus outperformed all software except Amberfin icr. Unfortunately I didn´t find any continuative hints in the linked intel documentation. Maybe direct access of the gpu scaler would be the best deinterlacing filter in ffmpeg, but I have no idea how this could work. So for now I´m finished with this patch. I hope it will be applied. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [FFmpeg-cvslog] avfilter/vf_bwdif: add x86 SIMD
>>>James Almer schrieb am So, 13.3.2016: > Since you adapted quite a bit of this code from yadif simd, the copyright > header should reflect that. Agreed. I´ll send a patch... ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avfilter/vf_bwdif: Add yadif base information to copyright header
Signed-off-by: Thomas Mundt --- libavfilter/x86/vf_bwdif.asm | 4 1 file changed, 4 insertions(+) diff --git a/libavfilter/x86/vf_bwdif.asm b/libavfilter/x86/vf_bwdif.asm index 11aa025..147b7c6 100644 --- a/libavfilter/x86/vf_bwdif.asm +++ b/libavfilter/x86/vf_bwdif.asm @@ -3,6 +3,10 @@ ;* ;* Copyright (C) 2016 Thomas Mundt ;* +;* Based on yadif simd code +;* Copyright (C) 2006 Michael Niedermayer +;* 2013 Daniel Kang +;* ;* This file is part of FFmpeg. ;* ;* FFmpeg is free software; you can redistribute it and/or -- 1.9.2 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 1/4] avfilter/vf_colormatrix: increase precision
Signed-off-by: Thomas Mundt
---
libavfilter/vf_colormatrix.c | 34 --
1 file changed, 20 insertions(+), 14 deletions(-)
diff --git a/libavfilter/vf_colormatrix.c b/libavfilter/vf_colormatrix.c
index 4a57fe0..ecd7a97 100644
--- a/libavfilter/vf_colormatrix.c
+++ b/libavfilter/vf_colormatrix.c
@@ -40,19 +40,11 @@
#define NS(n) ((n) < 0 ? (int)((n)*65536.0-0.5+DBL_EPSILON) :
(int)((n)*65536.0+0.5))
#define CB(n) av_clip_uint8(n)
-static const double yuv_coeff[4][3][3] = {
-{ { +0.7152, +0.0722, +0.2126 }, // Rec.709 (0)
- { -0.3850, +0.5000, -0.1150 },
- { -0.4540, -0.0460, +0.5000 } },
-{ { +0.5900, +0.1100, +0.3000 }, // FCC (1)
- { -0.3310, +0.5000, -0.1690 },
- { -0.4210, -0.0790, +0.5000 } },
-{ { +0.5870, +0.1140, +0.2990 }, // Rec.601 (ITU-R BT.470-2/SMPTE 170M) (2)
- { -0.3313, +0.5000, -0.1687 },
- { -0.4187, -0.0813, +0.5000 } },
-{ { +0.7010, +0.0870, +0.2120 }, // SMPTE 240M (3)
- { -0.3840, +0.5000, -0.1160 },
- { -0.4450, -0.0550, +0.5000 } },
+static const double yuv_coeff_luma[4][3] = {
+{ +0.7152, +0.0722, +0.2126 }, // Rec.709 (0)
+{ +0.5900, +0.1100, +0.3000 }, // FCC (1)
+{ +0.5870, +0.1140, +0.2990 }, // Rec.601 (ITU-R BT.470-2/SMPTE 170M) (2)
+{ +0.7010, +0.0870, +0.2120 }, // SMPTE 240M (3)
};
enum ColorMode {
@@ -148,11 +140,25 @@ static void solve_coefficients(double cm[3][3], double
rgb[3][3], const double y
static void calc_coefficients(AVFilterContext *ctx)
{
ColorMatrixContext *color = ctx->priv;
+double yuv_coeff[4][3][3];
double rgb_coeffd[4][3][3];
double yuv_convertd[16][3][3];
+double bscale, rscale;
int v = 0;
int i, j, k;
-
+for (i = 0; i < 4; i++) {
+yuv_coeff[i][0][0] = yuv_coeff_luma[i][0];
+yuv_coeff[i][0][1] = yuv_coeff_luma[i][1];
+yuv_coeff[i][0][2] = yuv_coeff_luma[i][2];
+bscale = 0.5 / (yuv_coeff[i][0][1] - 1.0);
+rscale = 0.5 / (yuv_coeff[i][0][2] - 1.0);
+yuv_coeff[i][1][0] = bscale * yuv_coeff[i][0][0];
+yuv_coeff[i][1][1] = 0.5;
+yuv_coeff[i][1][2] = bscale * yuv_coeff[i][0][2];
+yuv_coeff[i][2][0] = rscale * yuv_coeff[i][0][0];
+yuv_coeff[i][2][1] = rscale * yuv_coeff[i][0][1];
+yuv_coeff[i][2][2] = 0.5;
+}
for (i = 0; i < 4; i++)
inverse3x3(rgb_coeffd[i], yuv_coeff[i]);
for (i = 0; i < 4; i++) {
--
2.7.4.windows.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 2/4] avfilter/vf_colormatrix: add bt.2020 colorspace
Signed-off-by: Thomas Mundt
---
doc/filters.texi | 3 +++
libavfilter/vf_colormatrix.c | 38 ++
2 files changed, 25 insertions(+), 16 deletions(-)
diff --git a/doc/filters.texi b/doc/filters.texi
index 528e0f8..a438f6d 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -4880,6 +4880,9 @@ SMPTE-240M
@item fcc
FCC
+
+@item bt2020
+BT.2020
@end table
@end table
diff --git a/libavfilter/vf_colormatrix.c b/libavfilter/vf_colormatrix.c
index ecd7a97..6840b91 100644
--- a/libavfilter/vf_colormatrix.c
+++ b/libavfilter/vf_colormatrix.c
@@ -40,11 +40,12 @@
#define NS(n) ((n) < 0 ? (int)((n)*65536.0-0.5+DBL_EPSILON) :
(int)((n)*65536.0+0.5))
#define CB(n) av_clip_uint8(n)
-static const double yuv_coeff_luma[4][3] = {
+static const double yuv_coeff_luma[5][3] = {
{ +0.7152, +0.0722, +0.2126 }, // Rec.709 (0)
{ +0.5900, +0.1100, +0.3000 }, // FCC (1)
{ +0.5870, +0.1140, +0.2990 }, // Rec.601 (ITU-R BT.470-2/SMPTE 170M) (2)
{ +0.7010, +0.0870, +0.2120 }, // SMPTE 240M (3)
+{ +0.6780, +0.0593, +0.2627 }, // Rec.2020 (4)
};
enum ColorMode {
@@ -53,12 +54,13 @@ enum ColorMode {
COLOR_MODE_FCC,
COLOR_MODE_BT601,
COLOR_MODE_SMPTE240M,
+COLOR_MODE_BT2020,
COLOR_MODE_COUNT
};
typedef struct {
const AVClass *class;
-int yuv_convert[16][3][3];
+int yuv_convert[25][3][3];
int interlaced;
int source, dest;///< ColorMode
int mode;
@@ -89,6 +91,7 @@ static const AVOption colormatrix_options[] = {
{ "bt470bg", "set BT.470 colorspace", 0, AV_OPT_TYPE_CONST,
{.i64=COLOR_MODE_BT601}, .flags=FLAGS, .unit="color_mode" },
{ "smpte170m", "set SMTPE-170M colorspace", 0, AV_OPT_TYPE_CONST,
{.i64=COLOR_MODE_BT601}, .flags=FLAGS, .unit="color_mode" },
{ "smpte240m", "set SMPTE-240M colorspace", 0, AV_OPT_TYPE_CONST,
{.i64=COLOR_MODE_SMPTE240M}, .flags=FLAGS, .unit="color_mode" },
+{ "bt2020","set BT.2020 colorspace", 0, AV_OPT_TYPE_CONST,
{.i64=COLOR_MODE_BT2020}, .flags=FLAGS, .unit="color_mode" },
{ NULL }
};
@@ -140,13 +143,13 @@ static void solve_coefficients(double cm[3][3], double
rgb[3][3], const double y
static void calc_coefficients(AVFilterContext *ctx)
{
ColorMatrixContext *color = ctx->priv;
-double yuv_coeff[4][3][3];
-double rgb_coeffd[4][3][3];
-double yuv_convertd[16][3][3];
+double yuv_coeff[5][3][3];
+double rgb_coeffd[5][3][3];
+double yuv_convertd[25][3][3];
double bscale, rscale;
int v = 0;
int i, j, k;
-for (i = 0; i < 4; i++) {
+for (i = 0; i < 5; i++) {
yuv_coeff[i][0][0] = yuv_coeff_luma[i][0];
yuv_coeff[i][0][1] = yuv_coeff_luma[i][1];
yuv_coeff[i][0][2] = yuv_coeff_luma[i][2];
@@ -159,10 +162,10 @@ static void calc_coefficients(AVFilterContext *ctx)
yuv_coeff[i][2][1] = rscale * yuv_coeff[i][0][1];
yuv_coeff[i][2][2] = 0.5;
}
-for (i = 0; i < 4; i++)
+for (i = 0; i < 5; i++)
inverse3x3(rgb_coeffd[i], yuv_coeff[i]);
-for (i = 0; i < 4; i++) {
-for (j = 0; j < 4; j++) {
+for (i = 0; i < 5; i++) {
+for (j = 0; j < 5; j++) {
solve_coefficients(yuv_convertd[v], rgb_coeffd[i], yuv_coeff[j]);
for (k = 0; k < 3; k++) {
color->yuv_convert[v][k][0] = NS(yuv_convertd[v][k][0]);
@@ -178,7 +181,7 @@ static void calc_coefficients(AVFilterContext *ctx)
}
}
-static const char * const color_modes[] = {"bt709", "fcc", "bt601",
"smpte240m"};
+static const char * const color_modes[] = {"bt709", "fcc", "bt601",
"smpte240m", "bt2020"};
static av_cold int init(AVFilterContext *ctx)
{
@@ -441,20 +444,23 @@ static int filter_frame(AVFilterLink *link, AVFrame *in)
case AVCOL_SPC_SMPTE240M : source = COLOR_MODE_SMPTE240M ; break;
case AVCOL_SPC_BT470BG : source = COLOR_MODE_BT601 ; break;
case AVCOL_SPC_SMPTE170M : source = COLOR_MODE_BT601 ; break;
+case AVCOL_SPC_BT2020_NCL: source = COLOR_MODE_BT2020; break;
+case AVCOL_SPC_BT2020_CL : source = COLOR_MODE_BT2020; break;
default :
av_log(ctx, AV_LOG_ERROR, "Input frame does not specify a
supported colorspace, and none has been specified as source either\n");
av_frame_free(&out);
return AVERROR(EINVAL);
}
-color->mode = source * 4 + color->dest;
+color->mode = source * 5 + color->dest;
} else
-color->mode = color->source * 4 + color->dest;
+color->mode = color->source * 5 + color->dest;
switch(color->dest) {
-
[FFmpeg-devel] [PATCH 3/4] avfilter/vf_colormatrix: clean up and simplify calculations
Signed-off-by: Thomas Mundt
---
libavfilter/vf_colormatrix.c | 49 +++-
1 file changed, 21 insertions(+), 28 deletions(-)
diff --git a/libavfilter/vf_colormatrix.c b/libavfilter/vf_colormatrix.c
index 6840b91..5fe9ce3 100644
--- a/libavfilter/vf_colormatrix.c
+++ b/libavfilter/vf_colormatrix.c
@@ -38,7 +38,6 @@
#include "libavutil/avstring.h"
#define NS(n) ((n) < 0 ? (int)((n)*65536.0-0.5+DBL_EPSILON) :
(int)((n)*65536.0+0.5))
-#define CB(n) av_clip_uint8(n)
static const double yuv_coeff_luma[5][3] = {
{ +0.7152, +0.0722, +0.2126 }, // Rec.709 (0)
@@ -61,10 +60,8 @@ enum ColorMode {
typedef struct {
const AVClass *class;
int yuv_convert[25][3][3];
-int interlaced;
int source, dest;///< ColorMode
int mode;
-int hsub, vsub;
} ColorMatrixContext;
typedef struct ThreadData {
@@ -227,11 +224,11 @@ static int process_slice_uyvy422(AVFilterContext *ctx,
void *arg, int jobnr, int
for (x = 0; x < width; x += 4) {
const int u = srcp[x + 0] - 128;
const int v = srcp[x + 2] - 128;
-const int uvval = c2 * u + c3 * v + 1081344;
-dstp[x + 0] = CB((c4 * u + c5 * v + 8421376) >> 16);
-dstp[x + 1] = CB((65536 * (srcp[x + 1] - 16) + uvval) >> 16);
-dstp[x + 2] = CB((c6 * u + c7 * v + 8421376) >> 16);
-dstp[x + 3] = CB((65536 * (srcp[x + 3] - 16) + uvval) >> 16);
+const int uvval = (c2 * u + c3 * v + 32768) >> 16;
+dstp[x + 0] = av_clip_uint8((c4 * u + c5 * v + 8421376) >> 16);
+dstp[x + 1] = av_clip_uint8(srcp[x + 1] + uvval);
+dstp[x + 2] = av_clip_uint8((c6 * u + c7 * v + 8421376) >> 16);
+dstp[x + 3] = av_clip_uint8(srcp[x + 3] + uvval);
}
srcp += src_pitch;
dstp += dst_pitch;
@@ -271,10 +268,10 @@ static int process_slice_yuv444p(AVFilterContext *ctx,
void *arg, int jobnr, int
for (x = 0; x < width; x++) {
const int u = srcpU[x] - 128;
const int v = srcpV[x] - 128;
-const int uvval = c2 * u + c3 * v + 1081344;
-dstpY[x] = CB((65536 * (srcpY[x] - 16) + uvval) >> 16);
-dstpU[x] = CB((c4 * u + c5 * v + 8421376) >> 16);
-dstpV[x] = CB((c6 * u + c7 * v + 8421376) >> 16);
+const int uvval = (c2 * u + c3 * v + 32768) >> 16;
+dstpY[x] = av_clip_uint8(srcpY[x] + uvval);
+dstpU[x] = av_clip_uint8((c4 * u + c5 * v + 8421376) >> 16);
+dstpV[x] = av_clip_uint8((c6 * u + c7 * v + 8421376) >> 16);
}
srcpY += src_pitchY;
dstpY += dst_pitchY;
@@ -318,11 +315,11 @@ static int process_slice_yuv422p(AVFilterContext *ctx,
void *arg, int jobnr, int
for (x = 0; x < width; x += 2) {
const int u = srcpU[x >> 1] - 128;
const int v = srcpV[x >> 1] - 128;
-const int uvval = c2 * u + c3 * v + 1081344;
-dstpY[x + 0] = CB((65536 * (srcpY[x + 0] - 16) + uvval) >> 16);
-dstpY[x + 1] = CB((65536 * (srcpY[x + 1] - 16) + uvval) >> 16);
-dstpU[x >> 1] = CB((c4 * u + c5 * v + 8421376) >> 16);
-dstpV[x >> 1] = CB((c6 * u + c7 * v + 8421376) >> 16);
+const int uvval = (c2 * u + c3 * v + 32768) >> 16;
+dstpY[x + 0] = av_clip_uint8(srcpY[x + 0] + uvval);
+dstpY[x + 1] = av_clip_uint8(srcpY[x + 1] + uvval);
+dstpU[x >> 1] = av_clip_uint8((c4 * u + c5 * v + 8421376) >> 16);
+dstpV[x >> 1] = av_clip_uint8((c6 * u + c7 * v + 8421376) >> 16);
}
srcpY += src_pitchY;
dstpY += dst_pitchY;
@@ -368,13 +365,13 @@ static int process_slice_yuv420p(AVFilterContext *ctx,
void *arg, int jobnr, int
for (x = 0; x < width; x += 2) {
const int u = srcpU[x >> 1] - 128;
const int v = srcpV[x >> 1] - 128;
-const int uvval = c2 * u + c3 * v + 1081344;
-dstpY[x + 0] = CB((65536 * (srcpY[x + 0] - 16) + uvval) >> 16);
-dstpY[x + 1] = CB((65536 * (srcpY[x + 1] - 16) + uvval) >> 16);
-dstpN[x + 0] = CB((65536 * (srcpN[x + 0] - 16) + uvval) >> 16);
-dstpN[x + 1] = CB((65536 * (srcpN[x + 1] - 16) + uvval) >> 16);
-dstpU[x >> 1] = CB((c4 * u + c5 * v + 8421376) >> 16);
-dstpV[x >> 1] = CB((c6 * u + c7 * v + 8421376) >> 16);
+const int uvval = (c2 * u + c3 * v + 32768) >> 16;
+dstpY[x + 0] = av_clip_uint8(srcpY[x + 0] + uvval);
+dstpY[x + 1] = av_clip_uint8(srcpY[x + 1] + uvval);
+dstpN[x + 0] = av_clip_uint8(srcpN[x + 0] + uvval);
+dstpN[x + 1] = av_cl
[FFmpeg-devel] [PATCH 4/4] avfilter/vf_colormatrix: add 10 & 12 bit depth support
Signed-off-by: Thomas Mundt
---
libavfilter/vf_colormatrix.c | 182 ++-
1 file changed, 179 insertions(+), 3 deletions(-)
diff --git a/libavfilter/vf_colormatrix.c b/libavfilter/vf_colormatrix.c
index 5fe9ce3..92224b6 100644
--- a/libavfilter/vf_colormatrix.c
+++ b/libavfilter/vf_colormatrix.c
@@ -59,6 +59,7 @@ enum ColorMode {
typedef struct {
const AVClass *class;
+const AVPixFmtDescriptor *csp;
int yuv_convert[25][3][3];
int source, dest;///< ColorMode
int mode;
@@ -386,11 +387,177 @@ static int process_slice_yuv420p(AVFilterContext *ctx,
void *arg, int jobnr, int
return 0;
}
+static int process_slice_yuv444p_16bit(AVFilterContext *ctx, void *arg, int
jobnr, int nb_jobs)
+{
+const ThreadData *td = arg;
+const AVFrame *src = td->src;
+AVFrame *dst = td->dst;
+ColorMatrixContext *color = ctx->priv;
+const int numbits = 1 << color->csp->comp[0].depth;
+const int height = src->height;
+const int width = src->width;
+const int slice_start = (height * jobnr ) / nb_jobs;
+const int slice_end = (height * (jobnr+1)) / nb_jobs;
+const int src_pitchY = src->linesize[0] / 2;
+const int src_pitchUV = src->linesize[1] / 2;
+const uint16_t *srcpU = (const uint16_t *)src->data[1] + slice_start *
src_pitchUV;
+const uint16_t *srcpV = (const uint16_t *)src->data[2] + slice_start *
src_pitchUV;
+const uint16_t *srcpY = (const uint16_t *)src->data[0] + slice_start *
src_pitchY;
+const int dst_pitchY = dst->linesize[0] / 2;
+const int dst_pitchUV = dst->linesize[1] / 2;
+uint16_t *dstpU = (uint16_t *)dst->data[1] + slice_start * dst_pitchUV;
+uint16_t *dstpV = (uint16_t *)dst->data[2] + slice_start * dst_pitchUV;
+uint16_t *dstpY = (uint16_t *)dst->data[0] + slice_start * dst_pitchY;
+const int c2 = td->c2;
+const int c3 = td->c3;
+const int c4 = td->c4;
+const int c5 = td->c5;
+const int c6 = td->c6;
+const int c7 = td->c7;
+const int cin_shift = numbits >> 1;
+const int cout_shift = (numbits + 1) << 15;
+const int clip_max = numbits - 1;
+int x, y;
+
+for (y = slice_start; y < slice_end; y++) {
+for (x = 0; x < width; x++) {
+const int u = srcpU[x] - cin_shift;
+const int v = srcpV[x] - cin_shift;
+const int uvval = (c2 * u + c3 * v + 32768) >> 16;
+dstpY[x] = av_clip(srcpY[x] + uvval, 0, clip_max);
+dstpU[x] = av_clip((c4 * u + c5 * v + cout_shift) >> 16, 0,
clip_max);
+dstpV[x] = av_clip((c6 * u + c7 * v + cout_shift) >> 16, 0,
clip_max);
+}
+srcpY += src_pitchY;
+dstpY += dst_pitchY;
+srcpU += src_pitchUV;
+srcpV += src_pitchUV;
+dstpU += dst_pitchUV;
+dstpV += dst_pitchUV;
+}
+
+return 0;
+}
+
+static int process_slice_yuv422p_16bit(AVFilterContext *ctx, void *arg, int
jobnr, int nb_jobs)
+{
+const ThreadData *td = arg;
+const AVFrame *src = td->src;
+AVFrame *dst = td->dst;
+ColorMatrixContext *color = ctx->priv;
+const int numbits = 1 << color->csp->comp[0].depth;
+const int height = src->height;
+const int width = src->width;
+const int slice_start = (height * jobnr ) / nb_jobs;
+const int slice_end = (height * (jobnr+1)) / nb_jobs;
+const int src_pitchY = src->linesize[0] / 2;
+const int src_pitchUV = src->linesize[1] / 2;
+const uint16_t *srcpU = (const uint16_t *)src->data[1] + slice_start *
src_pitchUV;
+const uint16_t *srcpV = (const uint16_t *)src->data[2] + slice_start *
src_pitchUV;
+const uint16_t *srcpY = (const uint16_t *)src->data[0] + slice_start *
src_pitchY;
+const int dst_pitchY = dst->linesize[0] / 2;
+const int dst_pitchUV = dst->linesize[1] / 2;
+uint16_t *dstpU = (uint16_t *)dst->data[1] + slice_start * dst_pitchUV;
+uint16_t *dstpV = (uint16_t *)dst->data[2] + slice_start * dst_pitchUV;
+uint16_t *dstpY = (uint16_t *)dst->data[0] + slice_start * dst_pitchY;
+const int c2 = td->c2;
+const int c3 = td->c3;
+const int c4 = td->c4;
+const int c5 = td->c5;
+const int c6 = td->c6;
+const int c7 = td->c7;
+const int cin_shift = numbits >> 1;
+const int cout_shift = (numbits + 1) << 15;
+const int clip_max = numbits - 1;
+int x, y;
+
+for (y = slice_start; y < slice_end; y++) {
+for (x = 0; x < width; x += 2) {
+const int u = srcpU[x >> 1] - cin_shift;
+const int v = srcpV[x >> 1] - cin_shift;
+const int uvval = (c2 * u + c3 * v + 32768) >> 16;
+dstpY[x + 0] = av_clip(srcpY[x + 0] + uvval, 0, clip_max);
+dstpY[x + 1
[FFmpeg-devel] [PATCH 0/4] avfilter/vf_colormatrix: add UHD support
These patches add bt.2020 colorspace and 10 and 12 bit depth support. The calculation of the Y component is simplified but with identical results. Some unused variables are removed. The YUV croma coefficients are calculated instead of taken from a rough rounded table. Since these calculations happen only once the increased precision is worth it. Please comment. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
