[PATCH] Port tinterlace filter from MPlayer.
--- configure | 1 + doc/filters.texi | 26 +++++ libavfilter/Makefile | 1 + libavfilter/allfilters.c | 1 + libavfilter/avfilter.c | 2 +- libavfilter/vf_tinterlace.c | 260 +++++++++++++++++++++++++++++++++++++++++++ 6 files changed, 290 insertions(+), 1 deletions(-) create mode 100644 libavfilter/vf_tinterlace.c diff --git a/configure b/configure index 0538201..d3e2c14 100755 --- a/configure +++ b/configure @@ -1402,6 +1402,7 @@ udp_protocol_deps="network" # filters ocv_smooth_filter_deps="libopencv" +tinterlace_filter_deps="gpl" yadif_filter_deps="gpl" # libraries diff --git a/doc/filters.texi b/doc/filters.texi index d000276..3397989 100644 --- a/doc/filters.texi +++ b/doc/filters.texi @@ -390,6 +390,32 @@ not specified it will use the default value of 16. Adding this in the beginning of filter chains should make filtering faster due to better use of the memory cache. + at section tinterlace + +Perform temporal field interlacing - merge pairs of frames into an +interlaced frame, halving the framerate. Even frames are moved into +the upper field, odd frames to the lower field. + +The frames are counted starting from 1, so the first input frame is +considered odd. + +Accepts a parameters specifying the mode. Available modes are: + +0 Move odd frames into the upper field of the new frame, even into the + lower field, generating a double height frame at half framerate. + +1 Only output odd frames, even frames are dropped; height + unchanged, half framerate + +2 Only output even frames, odd frames are dropped; height + unchanged, half framerate + +3 Expand each frame to full height, but pad alternate lines with + black; framerate unchanged and double height. + +4 Interleave even lines from even frames with odd lines from odd + frames. Height unchanged at half framerate. + @section unsharp Sharpen or blur the input video. diff --git a/libavfilter/Makefile b/libavfilter/Makefile index 174b83e..431fe33 100644 --- a/libavfilter/Makefile +++ b/libavfilter/Makefile @@ -34,6 +34,7 @@ OBJS-$(CONFIG_PIXDESCTEST_FILTER) += vf_pixdesctest.o OBJS-$(CONFIG_PIXELASPECT_FILTER) += vf_aspect.o OBJS-$(CONFIG_SCALE_FILTER) += vf_scale.o OBJS-$(CONFIG_SLICIFY_FILTER) += vf_slicify.o +OBJS-$(CONFIG_TINTERLACE_FILTER) += vf_tinterlace.o OBJS-$(CONFIG_UNSHARP_FILTER) += vf_unsharp.o OBJS-$(CONFIG_VFLIP_FILTER) += vf_vflip.o OBJS-$(CONFIG_YADIF_FILTER) += vf_yadif.o diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c index ec7d933..5224fde 100644 --- a/libavfilter/allfilters.c +++ b/libavfilter/allfilters.c @@ -54,6 +54,7 @@ void avfilter_register_all(void) REGISTER_FILTER (PIXELASPECT, pixelaspect, vf); REGISTER_FILTER (SCALE, scale, vf); REGISTER_FILTER (SLICIFY, slicify, vf); + REGISTER_FILTER (TINTERLACE, tinterlace, vf); REGISTER_FILTER (UNSHARP, unsharp, vf); REGISTER_FILTER (VFLIP, vflip, vf); REGISTER_FILTER (YADIF, yadif, vf); diff --git a/libavfilter/avfilter.c b/libavfilter/avfilter.c index 221dfaa..72566e5 100644 --- a/libavfilter/avfilter.c +++ b/libavfilter/avfilter.c @@ -19,7 +19,7 @@ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA */ -/* #define DEBUG */ +#define DEBUG #include "libavcodec/audioconvert.c" #include "libavutil/pixdesc.h" diff --git a/libavfilter/vf_tinterlace.c b/libavfilter/vf_tinterlace.c new file mode 100644 index 0000000..771c6be --- /dev/null +++ b/libavfilter/vf_tinterlace.c @@ -0,0 +1,260 @@ +/* + * Copyright (C) 2010 Stefano Sabatini + * Copyright (C) 2003 Michael Zucchi <notzed at ximian.com> + * + * This file is part of FFmpeg. + * + * FFmpeg is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * FFmpeg is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License along + * with FFmpeg if not, write to the Free Software Foundation, Inc., + * 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA. + */ + +#include "libavcore/imgutils.h" +#include "avfilter.h" + +typedef struct { + /** + * 0: Move odd frames into the upper field of the new image, even into the lower field, generating a double-height video at half framerate. + * 1: Only output odd frames, even frames are dropped; height unchanged, half framerate + * 2: Only output even frames, odd frames are dropped; height unchanged, half framerate + * 3: Expand each frame to double height, but pad alternate lines with black; framerate unchanged. + * 4: Interleave even lines from even frames with odd lines from odd frames. Height unchanged at half framerate. + */ + int mode; + + int vsub; ///< chroma vertical subsampling + int frame; ///< frame number + int frame_pending; ///< tell if there is a pending frame ready to be sent + AVFilterBufferRef *picref; ///< previously stored picref +} TInterlaceContext; + +static int query_formats(AVFilterContext *ctx) +{ + static const enum PixelFormat pix_fmts[] = { + PIX_FMT_YUV420P, PIX_FMT_YUV422P, PIX_FMT_YUV410P, + PIX_FMT_YUV444P, PIX_FMT_GRAY8, PIX_FMT_NONE + }; + + avfilter_set_common_formats(ctx, avfilter_make_format_list(pix_fmts)); + + return 0; +} + +static av_cold int init(AVFilterContext *ctx, const char *args, void *opaque) +{ + TInterlaceContext *tinterlace = ctx->priv; + tinterlace->mode = 0; + tinterlace->picref = NULL; + tinterlace->frame = 1; + tinterlace->frame_pending = 0; + + if (args) sscanf(args, "%d", &tinterlace->mode); + + if (tinterlace->mode < 0 || tinterlace->mode > 4) { + av_log(ctx, AV_LOG_ERROR, + "Unknown mode %d, use a value between 0 and 4\n", tinterlace->mode); + return AVERROR(EINVAL); + } + + return 0; +} + +static av_cold void uninit(AVFilterContext *ctx) +{ + TInterlaceContext *tinterlace = ctx->priv; + + if (tinterlace->picref) avfilter_unref_buffer(tinterlace->picref); +} + +static int config_out_props(AVFilterLink *outlink) +{ + AVFilterContext *ctx = outlink->src; + AVFilterLink *inlink = outlink->src->inputs[0]; + TInterlaceContext *tinterlace = ctx->priv; + + tinterlace->vsub = av_pix_fmt_descriptors[outlink->format].log2_chroma_h; + outlink->w = inlink->w; + outlink->h = (tinterlace->mode == 0 || tinterlace->mode == 3) ? inlink->h*2 : inlink->h; + + av_log(ctx, AV_LOG_INFO, "mode:%d in_h:%d out_h:%d\n", + tinterlace->mode, inlink->h, outlink->h); + + return 0; +} + +static void copy_picture_fields(uint8_t *dst[4], int dst_linesize[4], + const uint8_t *src[4], int src_linesize[4], + enum PixelFormat format, int w, int + src_h, int lower_fields, + int only_half_src_fields, int src_lower_fields) +{ + int i, k = 1, vsub = av_pix_fmt_descriptors[format].log2_chroma_h; + if (only_half_src_fields) { + src_h /= 2; + k = 2; + } + + for (i = 0; i < 3; i++) { + int h = i == 1 || i == 2 ? src_h >> vsub : src_h; + int linesize = av_image_get_linesize(format, w, i); + + if (lower_fields) + dst[i] += dst_linesize[i]; + if (only_half_src_fields && src_lower_fields) + src[i] += src_linesize[i]; + av_image_copy_plane(dst[i], dst_linesize[i]*2, + src[i], src_linesize[i]*k, linesize, h); + } +} + +static void end_frame(AVFilterLink *inlink) +{ + AVFilterContext *ctx = inlink->dst; + AVFilterLink *outlink = ctx->outputs[0]; + TInterlaceContext *tinterlace = ctx->priv; + AVFilterBufferRef *outpicref; + AVFilterBufferRef *picref = inlink->cur_buf; + + if (tinterlace->mode == 0) { + if (!tinterlace->picref) { + outpicref = avfilter_get_video_buffer(outlink, AV_PERM_WRITE, outlink->w, outlink->h); + avfilter_copy_buffer_ref_props(outpicref, picref); + outpicref->video->w = outlink->w; + outpicref->video->h = outlink->h; + outpicref->video->interlaced = 1; + outpicref->video->top_field_first = 1; + + /* write odd frame fields into the upper fields of the new frame */ + copy_picture_fields(outpicref->data, outpicref->linesize, + picref ->data, picref ->linesize, + outlink->format, inlink->w, inlink->h, 0, 0, 0); + tinterlace->picref = outpicref; + } else { + outpicref = tinterlace->picref; + + /* write even frame fields into the lower fields of the new frame */ + copy_picture_fields(outpicref->data, outpicref->linesize, + picref ->data, picref ->linesize, + outlink->format, inlink->w, inlink->h, 1, 0, 0); + tinterlace->frame_pending = 1; + } + } else if ((tinterlace->mode == 1 && tinterlace->frame & 1) || /* send only odd frames */ + (tinterlace->mode == 2 && !(tinterlace->frame & 1))) { /* send only even frames */ + tinterlace->picref = avfilter_ref_buffer(picref, AV_PERM_READ); + tinterlace->frame_pending = 1; + } else if (tinterlace->mode == 3) { + outpicref = avfilter_get_video_buffer(outlink, AV_PERM_WRITE, outlink->w, outlink->h); + avfilter_copy_buffer_ref_props(outpicref, picref); + outpicref->video->w = outlink->w; + outpicref->video->h = outlink->h; + outpicref->video->interlaced = 1; + outpicref->video->top_field_first = tinterlace->frame & 1; + + /* cleanup the destination picture */ + memset(outpicref->data[0], 0, outpicref->linesize[0] * outlink->h); + if (outpicref->data[1]) + memset(outpicref->data[1], 128, outpicref->linesize[1] * (outlink->h >> tinterlace->vsub)); + if (outpicref->data[2]) + memset(outpicref->data[2], 128, outpicref->linesize[2] * (outlink->h >> tinterlace->vsub)); + + /* copy fields */ + copy_picture_fields(outpicref->data, outpicref->linesize, + picref ->data, picref ->linesize, + outlink->format, inlink->w, inlink->h, tinterlace->frame & 1, 0, 0); + tinterlace->picref = outpicref; + tinterlace->frame_pending = 1; + } else if (tinterlace->mode == 4) { + /* Interleave even lines from even frames with odd lines from odd frames. Height unchanged at half framerate. */ + if (!tinterlace->picref) { + outpicref = avfilter_get_video_buffer(outlink, AV_PERM_WRITE, outlink->w, outlink->h); + avfilter_copy_buffer_ref_props(outpicref, picref); + outpicref->video->w = outlink->w; + outpicref->video->h = outlink->h; + outpicref->video->interlaced = 1; + outpicref->video->top_field_first = 1; + + /* write odd frame odd fields into the upper fields of the new frame */ + copy_picture_fields(outpicref->data, outpicref->linesize, + picref ->data, picref ->linesize, + outlink->format, inlink->w, inlink->h, 0, 1, 0); + tinterlace->picref = outpicref; + } else { + outpicref = tinterlace->picref; + + /* write even frame even fields into the lower fields of the new frame */ + copy_picture_fields(outpicref->data, outpicref->linesize, + picref ->data, picref ->linesize, + outlink->format, inlink->w, inlink->h, 1, 1, 1); + tinterlace->frame_pending = 1; + } + } + + tinterlace->frame++; + avfilter_unref_buffer(inlink->cur_buf); +} + +static void null_start_frame(AVFilterLink *inlink, AVFilterBufferRef *picref) { } + +static int request_frame(AVFilterLink *outlink) +{ + AVFilterContext *ctx = outlink->src; + TInterlaceContext *tinterlace = ctx->priv; + + while (!tinterlace->frame_pending) { + int ret; + + if ((ret = avfilter_request_frame(outlink->src->inputs[0]))) + return ret; + } + + avfilter_start_frame(outlink, tinterlace->picref); + avfilter_draw_slice(outlink, 0, outlink->h, 1); + avfilter_end_frame(outlink); + tinterlace->picref = NULL; + tinterlace->frame_pending = 0; + return 0; +} + +static int poll_frame(AVFilterLink *outlink) +{ + TInterlaceContext *tinterlace = outlink->src->priv; + + return tinterlace->frame_pending; +} + +static void null_draw_slice(AVFilterLink *link, int y, int h, int slice_dir) { } + +AVFilter avfilter_vf_tinterlace = { + .name = "tinterlace", + .description = NULL_IF_CONFIG_SMALL("Perform temporal field interlacing."), + + .priv_size = sizeof(TInterlaceContext), + .init = init, + .uninit = uninit, + .query_formats = query_formats, + + .inputs = (AVFilterPad[]) {{ .name = "default", + .type = AVMEDIA_TYPE_VIDEO, + .start_frame = null_start_frame, + .draw_slice = null_draw_slice, + .end_frame = end_frame, }, + { .name = NULL}}, + + .outputs = (AVFilterPad[]) {{ .name = "default", + .type = AVMEDIA_TYPE_VIDEO, + .config_props = config_out_props, + .poll_frame = poll_frame, + .request_frame = request_frame, }, + + { .name = NULL}}, +}; -- 1.7.1
On date Sunday 2010-09-26 19:17:02 +0200, Stefano Sabatini encoded:
--- configure | 1 + doc/filters.texi | 26 +++++ libavfilter/Makefile | 1 + libavfilter/allfilters.c | 1 + libavfilter/avfilter.c | 2 +- libavfilter/vf_tinterlace.c | 260 +++++++++++++++++++++++++++++++++++++++++++ 6 files changed, 290 insertions(+), 1 deletions(-) create mode 100644 libavfilter/vf_tinterlace.c
Updated with some refactoring. This is useful e.g. for testing yadif and other kind of deinterlacing. There is still a problem which is causing green artifacts in the lower row of the interlaced image, help and hints are welcome. Regards. -- FFmpeg = Fast and Frightening Mastering Pitiless Evil Geisha
On Sun, Sep 26, 2010 at 07:32:45PM +0200, Stefano Sabatini wrote: [...]
+static void end_frame(AVFilterLink *inlink) +{ + AVFilterContext *ctx = inlink->dst; + AVFilterLink *outlink = ctx->outputs[0]; + TInterlaceContext *tinterlace = ctx->priv; + AVFilterBufferRef *outpicref; + AVFilterBufferRef *picref = inlink->cur_buf; + + if (tinterlace->mode == 0 || tinterlace->mode == 4) { + int half_src_fields = tinterlace->mode == 4; + + if (!tinterlace->picref) { + outpicref = avfilter_get_video_buffer(outlink, AV_PERM_WRITE, outlink->w, outlink->h); + avfilter_copy_buffer_ref_props(outpicref, picref); + outpicref->video->w = outlink->w; + outpicref->video->h = outlink->h; + outpicref->video->interlaced = 1; + outpicref->video->top_field_first = 1; + + /* write odd frame fields into the upper fields of the new frame */ + copy_picture_fields(outpicref->data, outpicref->linesize, + picref ->data, picref ->linesize, + outlink->format, inlink->w, inlink->h, 0, half_src_fields, 0); + tinterlace->picref = outpicref; + } else { + outpicref = tinterlace->picref; + + /* write even frame fields into the lower fields of the new frame */ + copy_picture_fields(outpicref->data, outpicref->linesize, + picref ->data, picref ->linesize, + outlink->format, inlink->w, inlink->h, 1, half_src_fields, half_src_fields); + tinterlace->frame_pending = 1; + } + } else if ((tinterlace->mode == 1 && tinterlace->frame & 1) || /* send only odd frames */ + (tinterlace->mode == 2 && !(tinterlace->frame & 1))) { /* send only even frames */ + tinterlace->picref = avfilter_ref_buffer(picref, AV_PERM_READ); + tinterlace->frame_pending = 1; + } else if (tinterlace->mode == 3) { + outpicref = avfilter_get_video_buffer(outlink, AV_PERM_WRITE, outlink->w, outlink->h); + avfilter_copy_buffer_ref_props(outpicref, picref); + outpicref->video->w = outlink->w; + outpicref->video->h = outlink->h; + outpicref->video->interlaced = 1; + outpicref->video->top_field_first = tinterlace->frame & 1; + + /* cleanup the destination picture */ + memset(outpicref->data[0], 0, outpicref->linesize[0] * outlink->h); + if (outpicref->data[1]) + memset(outpicref->data[1], 128, outpicref->linesize[1] * (outlink->h >> tinterlace->vsub)); + if (outpicref->data[2]) + memset(outpicref->data[2], 128, outpicref->linesize[2] * (outlink->h >> tinterlace->vsub)); + + /* copy fields */ + copy_picture_fields(outpicref->data, outpicref->linesize, + picref ->data, picref ->linesize, + outlink->format, inlink->w, inlink->h, tinterlace->frame & 1, 0, 0); + tinterlace->picref = outpicref; + tinterlace->frame_pending = 1; + } + + tinterlace->frame++; + avfilter_unref_buffer(inlink->cur_buf); +} + +static void null_start_frame(AVFilterLink *inlink, AVFilterBufferRef *picref) { } + +static int request_frame(AVFilterLink *outlink) +{ + AVFilterContext *ctx = outlink->src; + TInterlaceContext *tinterlace = ctx->priv; + + while (!tinterlace->frame_pending) { + int ret; + + if ((ret = avfilter_request_frame(outlink->src->inputs[0]))) + return ret; + } + + avfilter_start_frame(outlink, tinterlace->picref); + avfilter_draw_slice(outlink, 0, outlink->h, 1); + avfilter_end_frame(outlink); + tinterlace->picref = NULL; + tinterlace->frame_pending = 0; + return 0; +}
imagine your filter is called with start_frame/draw_slice/end_frame but no request_frame (this happens after a split filter for example)
+ +static int poll_frame(AVFilterLink *outlink) +{ + TInterlaceContext *tinterlace = outlink->src->priv; + + return tinterlace->frame_pending; +}
this doesnt look correct [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB I have never wished to cater to the crowd; for what I know they do not approve, and what they approve I do not know. -- Epicurus
On date Sunday 2010-09-26 20:32:48 +0200, Michael Niedermayer wrote:
On Sun, Sep 26, 2010 at 07:32:45PM +0200, Stefano Sabatini wrote: [...]
+static int request_frame(AVFilterLink *outlink) +{ + AVFilterContext *ctx = outlink->src; + TInterlaceContext *tinterlace = ctx->priv; + + while (!tinterlace->frame_pending) { + int ret; + + if ((ret = avfilter_request_frame(outlink->src->inputs[0]))) + return ret; + } + + avfilter_start_frame(outlink, tinterlace->picref); + avfilter_draw_slice(outlink, 0, outlink->h, 1); + avfilter_end_frame(outlink); + tinterlace->picref = NULL; + tinterlace->frame_pending = 0; + return 0; +}
imagine your filter is called with start_frame/draw_slice/end_frame but no request_frame (this happens after a split filter for example)
+ +static int poll_frame(AVFilterLink *outlink) +{ + TInterlaceContext *tinterlace = outlink->src->priv; + + return tinterlace->frame_pending; +}
this doesnt look correct
Updated based on the tinterlace port from FFmbc, with some simplifications. Depends on the vsink_buffer which I'm going to send soon. -- If someone had told me I would be Pope one day, I would have studied harder. -- Pope John Paul I
On date Monday 2011-06-27 23:49:09 +0200, Stefano Sabatini encoded:
On date Sunday 2010-09-26 20:32:48 +0200, Michael Niedermayer wrote: [...] Updated based on the tinterlace port from FFmbc, with some simplifications.
Updated again, with a request_frame() implementation. Some questions: 1) what do we want to do with the limpcodecs wrapper as they are ported to native filters? (I suppose the right answer is "drop them" => less code to maintain, in this case mpcodecs/tinterlace is broken and in general fixing those filters - with no previous knowledge of libmpcodecs - requires more time than porting them). 2) Regarding mode 3: |Expand each frame to full height, but pad alternate lines with |black; framerate unchanged and double height. the padded lines are always the even lines, if I'm not wrong real television devices alternate even and odd lines scanning, which in this case generate a very fastidious flickering effect (which theoretically should not be not be perceived at high framerates). I can add another mode (would be "5" for retaining MPlayer compatibility), for implementing this behavior, I'd like to hear some interlace "experts" opinion regarding this. -- FFmpeg = Fantastic and Fabulous Marvellous Pitiless ExchanGer
On 6/28/11, Stefano Sabatini <stefano.sabatini-lala@poste.it> wrote:
On date Monday 2011-06-27 23:49:09 +0200, Stefano Sabatini encoded:
On date Sunday 2010-09-26 20:32:48 +0200, Michael Niedermayer wrote: [...] Updated based on the tinterlace port from FFmbc, with some simplifications.
Updated again, with a request_frame() implementation.
Some questions:
1) what do we want to do with the limpcodecs wrapper as they are ported to native filters? (I suppose the right answer is "drop them" => less code to maintain, in this case mpcodecs/tinterlace is broken and in general fixing those filters - with no previous knowledge of libmpcodecs - requires more time than porting them).
IMHO, once the native is working fine, remove the other.
2) Regarding mode 3: |Expand each frame to full height, but pad alternate lines with |black; framerate unchanged and double height.
the padded lines are always the even lines, if I'm not wrong real television devices alternate even and odd lines scanning, which in this case generate a very fastidious flickering effect (which theoretically should not be not be perceived at high framerates).
I can add another mode (would be "5" for retaining MPlayer compatibility), for implementing this behavior, I'd like to hear some interlace "experts" opinion regarding this.
Mode 3 of this filter is working as advertised, at least in mplayer. I have no idea why it doesn't work for you, as the source code is looking quite straight forward: (pseudo code;) case 3: if(vf->priv->frame&1 ==0) {copy_pic(plane,stride*2) } else {copypic(plane+stride, stride*2); }; output(); break; vf->priv->frame++; If you want to make mode 5, you can make it like mode 3 but double the framerate. aka: take 1 frame, output top_field of the frame and black the other. output bottom_field of the frame and black the other. repeat. Best Regards.
On date Tuesday 2011-06-28 13:08:23 +0300, Ivan Kalvachev encoded:
On 6/28/11, Stefano Sabatini <stefano.sabatini-lala@poste.it> wrote: [...]
2) Regarding mode 3: |Expand each frame to full height, but pad alternate lines with |black; framerate unchanged and double height.
the padded lines are always the even lines, if I'm not wrong real television devices alternate even and odd lines scanning, which in this case generate a very fastidious flickering effect (which theoretically should not be not be perceived at high framerates).
I can add another mode (would be "5" for retaining MPlayer compatibility), for implementing this behavior, I'd like to hear some interlace "experts" opinion regarding this.
Mode 3 of this filter is working as advertised, at least in mplayer. I have no idea why it doesn't work for you, as the source code is looking quite straight forward: (pseudo code;) case 3: if(vf->priv->frame&1 ==0) {copy_pic(plane,stride*2) } else {copypic(plane+stride, stride*2); }; output(); break; vf->priv->frame++;
If you want to make mode 5, you can make it like mode 3 but double the framerate. aka: take 1 frame, output top_field of the frame and black the other. output bottom_field of the frame and black the other. repeat.
There is nothing wrong with mode 3, but I wonder if it makes sense to implement this mode 5 (easily done with ~5 lines of code) for "emulating" television devices. -- FFmpeg = Fundamental and Foolish Murdering Perennial Enhanced Gadget
On Tue, Jun 28, 2011 at 01:08:23PM +0300, Ivan Kalvachev wrote:
On 6/28/11, Stefano Sabatini <stefano.sabatini-lala@poste.it> wrote:
On date Monday 2011-06-27 23:49:09 +0200, Stefano Sabatini encoded:
On date Sunday 2010-09-26 20:32:48 +0200, Michael Niedermayer wrote: [...] Updated based on the tinterlace port from FFmbc, with some simplifications.
Updated again, with a request_frame() implementation.
Some questions:
1) what do we want to do with the limpcodecs wrapper as they are ported to native filters? (I suppose the right answer is "drop them" => less code to maintain, in this case mpcodecs/tinterlace is broken and in general fixing those filters - with no previous knowledge of libmpcodecs - requires more time than porting them).
IMHO, once the native is working fine, remove the other.
agree also once you and stefano agree on the patch, consider it approved by me too. iam too busy to double review and you are a pretty good developer who i would hope to be more active :) [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Good people do not need laws to tell them to act responsibly, while bad people will find a way around the laws. -- Plato
On date Wednesday 2011-06-29 05:43:18 +0200, Michael Niedermayer encoded:
On Tue, Jun 28, 2011 at 01:08:23PM +0300, Ivan Kalvachev wrote:
On 6/28/11, Stefano Sabatini <stefano.sabatini-lala@poste.it> wrote:
On date Monday 2011-06-27 23:49:09 +0200, Stefano Sabatini encoded:
On date Sunday 2010-09-26 20:32:48 +0200, Michael Niedermayer wrote: [...] Updated based on the tinterlace port from FFmbc, with some simplifications.
Updated again, with a request_frame() implementation.
Some questions:
1) what do we want to do with the limpcodecs wrapper as they are ported to native filters? (I suppose the right answer is "drop them" => less code to maintain, in this case mpcodecs/tinterlace is broken and in general fixing those filters - with no previous knowledge of libmpcodecs - requires more time than porting them).
IMHO, once the native is working fine, remove the other.
agree also once you and stefano agree on the patch, consider it approved by me too. iam too busy to double review and you are a pretty good developer who i would hope to be more active :)
Updated with more fixes. I withdraw the "mode 5" ideas, since it requires some more changes to the framework which are not related to the port. -- FFmpeg = Funny and Faithful Mysterious Pitiful Ecstatic Guru
On date Thursday 2011-06-30 10:15:15 +0200, Stefano Sabatini encoded:
On date Wednesday 2011-06-29 05:43:18 +0200, Michael Niedermayer encoded:
On Tue, Jun 28, 2011 at 01:08:23PM +0300, Ivan Kalvachev wrote:
On 6/28/11, Stefano Sabatini <stefano.sabatini-lala@poste.it> wrote:
On date Monday 2011-06-27 23:49:09 +0200, Stefano Sabatini encoded:
On date Sunday 2010-09-26 20:32:48 +0200, Michael Niedermayer wrote: [...] Updated based on the tinterlace port from FFmbc, with some simplifications.
Updated again, with a request_frame() implementation.
Some questions:
1) what do we want to do with the limpcodecs wrapper as they are ported to native filters? (I suppose the right answer is "drop them" => less code to maintain, in this case mpcodecs/tinterlace is broken and in general fixing those filters - with no previous knowledge of libmpcodecs - requires more time than porting them).
IMHO, once the native is working fine, remove the other.
agree also once you and stefano agree on the patch, consider it approved by me too. iam too busy to double review and you are a pretty good developer who i would hope to be more active :)
Updated with more fixes.
I withdraw the "mode 5" ideas, since it requires some more changes to the framework which are not related to the port.
Regarding this patch, I'd appreciate some comments from Baptiste regarding this part: [...]
+static int poll_frame(AVFilterLink *outlink) +{ + TInterlaceContext *tinterlace = outlink->src->priv; + AVFilterLink *inlink = outlink->src->inputs[0]; + int ret, val; + + val = avfilter_poll_frame(inlink); + + if (val == 1 && !tinterlace->next) { //FIXME change API to not requre this red tape + if ((ret = avfilter_request_frame(inlink)) < 0) + return ret; + val = avfilter_poll_frame(inlink); + } + assert(tinterlace->next); + + return val; +}
I copied the comment verbatim, can you elaborate on that? Regarding the "mode 5", I'm considering to write a separate filter for that, and call it something like "tvinterlace" since it would be quite different with respect to this (takes one picture -> returns two), and I want to avoid to complicate the logic of this filter more (while some routines can be shared amongst the two). -- FFmpeg = Formidable and Fierce Mega Portentous Enhanced Gigant
On date Friday 2011-07-01 11:00:41 +0200, Stefano Sabatini encoded:
On date Thursday 2011-06-30 10:15:15 +0200, Stefano Sabatini encoded:
On date Wednesday 2011-06-29 05:43:18 +0200, Michael Niedermayer encoded:
On Tue, Jun 28, 2011 at 01:08:23PM +0300, Ivan Kalvachev wrote:
On 6/28/11, Stefano Sabatini <stefano.sabatini-lala@poste.it> wrote:
On date Monday 2011-06-27 23:49:09 +0200, Stefano Sabatini encoded:
On date Sunday 2010-09-26 20:32:48 +0200, Michael Niedermayer wrote: [...] Updated based on the tinterlace port from FFmbc, with some simplifications.
Updated again, with a request_frame() implementation.
Some questions:
1) what do we want to do with the limpcodecs wrapper as they are ported to native filters? (I suppose the right answer is "drop them" => less code to maintain, in this case mpcodecs/tinterlace is broken and in general fixing those filters - with no previous knowledge of libmpcodecs - requires more time than porting them).
IMHO, once the native is working fine, remove the other.
agree also once you and stefano agree on the patch, consider it approved by me too. iam too busy to double review and you are a pretty good developer who i would hope to be more active :)
Updated with more fixes.
I withdraw the "mode 5" ideas, since it requires some more changes to the framework which are not related to the port.
Regarding this patch, I'd appreciate some comments from Baptiste regarding this part:
[...]
+static int poll_frame(AVFilterLink *outlink) +{ + TInterlaceContext *tinterlace = outlink->src->priv; + AVFilterLink *inlink = outlink->src->inputs[0]; + int ret, val; + + val = avfilter_poll_frame(inlink); + + if (val == 1 && !tinterlace->next) { //FIXME change API to not requre this red tape + if ((ret = avfilter_request_frame(inlink)) < 0) + return ret; + val = avfilter_poll_frame(inlink); + } + assert(tinterlace->next); + + return val; +}
I copied the comment verbatim, can you elaborate on that?
Regarding the "mode 5", I'm considering to write a separate filter for that, and call it something like "tvinterlace" since it would be quite different with respect to this (takes one picture -> returns two), and I want to avoid to complicate the logic of this filter more (while some routines can be shared amongst the two).
Updated, tested against the mp=tinterlace filter, same output is issued (but mp=tinterlace has broken PTSes all set to 0), only difference is in mode 3 where tinterlace correctly set pad lines luma values to 16 rather than to 0. -- FFmpeg = Frenzy and Foolish Multimedia Patchable Empowered Gadget
On Sun, Aug 28, 2011 at 02:49:13AM +0200, Stefano Sabatini wrote:
On date Friday 2011-07-01 11:00:41 +0200, Stefano Sabatini encoded:
On date Thursday 2011-06-30 10:15:15 +0200, Stefano Sabatini encoded:
On date Wednesday 2011-06-29 05:43:18 +0200, Michael Niedermayer encoded:
On Tue, Jun 28, 2011 at 01:08:23PM +0300, Ivan Kalvachev wrote:
On 6/28/11, Stefano Sabatini <stefano.sabatini-lala@poste.it> wrote:
On date Monday 2011-06-27 23:49:09 +0200, Stefano Sabatini encoded: > On date Sunday 2010-09-26 20:32:48 +0200, Michael Niedermayer wrote: [...] > Updated based on the tinterlace port from FFmbc, with some > simplifications.
Updated again, with a request_frame() implementation.
Some questions:
1) what do we want to do with the limpcodecs wrapper as they are ported to native filters? (I suppose the right answer is "drop them" => less code to maintain, in this case mpcodecs/tinterlace is broken and in general fixing those filters - with no previous knowledge of libmpcodecs - requires more time than porting them).
IMHO, once the native is working fine, remove the other.
agree also once you and stefano agree on the patch, consider it approved by me too. iam too busy to double review and you are a pretty good developer who i would hope to be more active :)
Updated with more fixes.
I withdraw the "mode 5" ideas, since it requires some more changes to the framework which are not related to the port.
Regarding this patch, I'd appreciate some comments from Baptiste regarding this part:
[...]
+static int poll_frame(AVFilterLink *outlink) +{ + TInterlaceContext *tinterlace = outlink->src->priv; + AVFilterLink *inlink = outlink->src->inputs[0]; + int ret, val; + + val = avfilter_poll_frame(inlink); + + if (val == 1 && !tinterlace->next) { //FIXME change API to not requre this red tape + if ((ret = avfilter_request_frame(inlink)) < 0) + return ret; + val = avfilter_poll_frame(inlink); + } + assert(tinterlace->next); + + return val; +}
I copied the comment verbatim, can you elaborate on that?
Regarding the "mode 5", I'm considering to write a separate filter for that, and call it something like "tvinterlace" since it would be quite different with respect to this (takes one picture -> returns two), and I want to avoid to complicate the logic of this filter more (while some routines can be shared amongst the two).
Updated, tested against the mp=tinterlace filter, same output is issued (but mp=tinterlace has broken PTSes all set to 0), only difference is in mode 3 where tinterlace correctly set pad lines luma values to 16 rather than to 0.
If it supports the same syntax, same or more features and no code was lost in the porting and its same speed or faster then it should be ok thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB When you are offended at any man's fault, turn to yourself and study your own failings. Then you will forget your anger. -- Epictetus
On date Monday 2011-08-29 03:16:43 +0200, Michael Niedermayer encoded:
On Sun, Aug 28, 2011 at 02:49:13AM +0200, Stefano Sabatini wrote: [...]
Updated, tested against the mp=tinterlace filter, same output is issued (but mp=tinterlace has broken PTSes all set to 0), only difference is in mode 3 where tinterlace correctly set pad lines luma values to 16 rather than to 0.
If it supports the same syntax, same or more features and no code was lost in the porting and its same speed or faster then it should be ok
Main difference from the performance point of view is that tinterlace calls copy_picture_fields(), I can inline it for improving performance. Apart from that, vf_tinterlace.c looks more complex of the corresponding vf_tinterlace.c libmpcodecs code - 326 vs. 236 LOC (lavfi tends to be more verbose, and I added more checks and docs for internal functions). I'm going to apply the patch in a few days if I see no comments, then I'll remove the mp=tinterlace wrapper if there are no objections. -- FFmpeg = Fantastic and Foolish Marvellous Picky Entertaining Gadget
On Tue, Aug 30, 2011 at 10:50:12AM +0200, Stefano Sabatini wrote:
On date Monday 2011-08-29 03:16:43 +0200, Michael Niedermayer encoded:
On Sun, Aug 28, 2011 at 02:49:13AM +0200, Stefano Sabatini wrote: [...]
Updated, tested against the mp=tinterlace filter, same output is issued (but mp=tinterlace has broken PTSes all set to 0), only difference is in mode 3 where tinterlace correctly set pad lines luma values to 16 rather than to 0.
If it supports the same syntax, same or more features and no code was lost in the porting and its same speed or faster then it should be ok
Main difference from the performance point of view is that tinterlace calls copy_picture_fields(), I can inline it for improving performance.
Apart from that, vf_tinterlace.c looks more complex of the corresponding vf_tinterlace.c libmpcodecs code - 326 vs. 236 LOC (lavfi tends to be more verbose, and I added more checks and docs for internal functions).
I'm going to apply the patch in a few days if I see no comments, then I'll remove the mp=tinterlace wrapper if there are no objections.
I think the mp filters should only be removed once mplayer switched to libavfilter The issue i see is mplayers will be improved and our native ones might rot and then its nice to still have the wraper. [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Democracy is the form of government in which you can choose your dictator
On date Tuesday 2011-08-30 20:37:36 +0200, Michael Niedermayer encoded:
On Tue, Aug 30, 2011 at 10:50:12AM +0200, Stefano Sabatini wrote:
On date Monday 2011-08-29 03:16:43 +0200, Michael Niedermayer encoded:
On Sun, Aug 28, 2011 at 02:49:13AM +0200, Stefano Sabatini wrote: [...]
Updated, tested against the mp=tinterlace filter, same output is issued (but mp=tinterlace has broken PTSes all set to 0), only difference is in mode 3 where tinterlace correctly set pad lines luma values to 16 rather than to 0.
If it supports the same syntax, same or more features and no code was lost in the porting and its same speed or faster then it should be ok
Main difference from the performance point of view is that tinterlace calls copy_picture_fields(), I can inline it for improving performance.
Apart from that, vf_tinterlace.c looks more complex of the corresponding vf_tinterlace.c libmpcodecs code - 326 vs. 236 LOC (lavfi tends to be more verbose, and I added more checks and docs for internal functions).
I'm going to apply the patch in a few days if I see no comments, then I'll remove the mp=tinterlace wrapper if there are no objections.
I think the mp filters should only be removed once mplayer switched to libavfilter The issue i see is mplayers will be improved and our native ones might rot and then its nice to still have the wraper.
Yes, but 1. it's not sure it will switch to lavfi, 2. we'll need to keep them updated. Anyway having the duplicated code doesn't particularly bother me, my only point is that sometimes the mp filters don't work very well (e.g. mp=tinterlace resets timestamps to 0), in that case maybe it's better to just remove them rather than having the user to discover that the wrapped filter doesn't work as expected. -- FFmpeg = Fantastic and Fancy Murdering Peaceful ExchanGer
On Tue, Aug 30, 2011 at 11:53:10PM +0200, Stefano Sabatini wrote:
On date Tuesday 2011-08-30 20:37:36 +0200, Michael Niedermayer encoded:
On Tue, Aug 30, 2011 at 10:50:12AM +0200, Stefano Sabatini wrote:
On date Monday 2011-08-29 03:16:43 +0200, Michael Niedermayer encoded:
On Sun, Aug 28, 2011 at 02:49:13AM +0200, Stefano Sabatini wrote: [...]
Updated, tested against the mp=tinterlace filter, same output is issued (but mp=tinterlace has broken PTSes all set to 0), only difference is in mode 3 where tinterlace correctly set pad lines luma values to 16 rather than to 0.
If it supports the same syntax, same or more features and no code was lost in the porting and its same speed or faster then it should be ok
Main difference from the performance point of view is that tinterlace calls copy_picture_fields(), I can inline it for improving performance.
Apart from that, vf_tinterlace.c looks more complex of the corresponding vf_tinterlace.c libmpcodecs code - 326 vs. 236 LOC (lavfi tends to be more verbose, and I added more checks and docs for internal functions).
I'm going to apply the patch in a few days if I see no comments, then I'll remove the mp=tinterlace wrapper if there are no objections.
I think the mp filters should only be removed once mplayer switched to libavfilter The issue i see is mplayers will be improved and our native ones might rot and then its nice to still have the wraper.
Yes, but 1. it's not sure it will switch to lavfi, 2. we'll need to keep them updated.
If mplayer doesnt switch to lavfi then i think its less work to keep the libmpcodecs copy updated and fix the remaining bugs in the wraper than keeping the ported filters updated. Which is why i suggested to keep the filters (until and if) mplayer switches to lavfi Its of course also not a big thing to resurrect the filters from git history if the need arrises [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB It is dangerous to be right in matters on which the established authorities are wrong. -- Voltaire
Hi Stefano! Stefano Sabatini wrote:
On date Tuesday 2011-08-30 20:37:36 +0200, Michael Niedermayer encoded:
On Tue, Aug 30, 2011 at 10:50:12AM +0200, Stefano Sabatini wrote: [...]
I'm going to apply the patch in a few days if I see no comments, then I'll remove the mp=tinterlace wrapper if there are no objections.
I think the mp filters should only be removed once mplayer switched to libavfilter The issue i see is mplayers will be improved and our native ones might rot and then its nice to still have the wraper.
Yes, but 1. it's not sure it will switch to lavfi, 2. we'll need to keep them updated.
Anyway having the duplicated code doesn't particularly bother me, my only point is that sometimes the mp filters don't work very well (e.g. mp=tinterlace resets timestamps to 0), in that case maybe it's better to just remove them rather than having the user to discover that the wrapped filter doesn't work as expected.
While they are potentially developed at two places, it might be handy to have the wrapped filter around and test against it when updating the lavfi implementation to accomodate a change in MPlayer. I am not very passionate about keeping it though. Just wanted to point out that it might be useful. Maybe ffmpeg could output a message if a user selected the wrapped mp filter and an lavfi replacement is available. That would probably only be worth it if we decide on generally keeping the wrapped filters around (until they are deleted from MPlayer repo). Alexander
On date Tuesday 2011-08-30 10:50:12 +0200, Stefano Sabatini encoded:
On date Monday 2011-08-29 03:16:43 +0200, Michael Niedermayer encoded:
On Sun, Aug 28, 2011 at 02:49:13AM +0200, Stefano Sabatini wrote: [...]
Updated, tested against the mp=tinterlace filter, same output is issued (but mp=tinterlace has broken PTSes all set to 0), only difference is in mode 3 where tinterlace correctly set pad lines luma values to 16 rather than to 0.
If it supports the same syntax, same or more features and no code was lost in the porting and its same speed or faster then it should be ok
Main difference from the performance point of view is that tinterlace calls copy_picture_fields(), I can inline it for improving performance.
Apart from that, vf_tinterlace.c looks more complex of the corresponding vf_tinterlace.c libmpcodecs code - 326 vs. 236 LOC (lavfi tends to be more verbose, and I added more checks and docs for internal functions).
I'm going to apply the patch in a few days if I see no comments, then I'll remove the mp=tinterlace wrapper if there are no objections. [...]
Updated with misc cosmetics for improving readability, I'll apply soon if I read no comments. -- FFmpeg = Fascinating and Forgiving Magical Pacific Evangelical God
On date Tuesday 2011-08-30 10:50:12 +0200, Stefano Sabatini encoded: [...]
I'm going to apply the patch in a few days if I see no comments, then I'll remove the mp=tinterlace wrapper if there are no objections. [...]
Updated with misc cosmetics for improving readability, I'll apply soon if I read no comments.
27.12.11 14:08, Stefano Sabatini написав(ла): ping? -- ________________________________________ Maksym Veremeyenko
On date Tuesday 2011-12-27 13:08:52 +0100, Stefano Sabatini encoded:
On date Tuesday 2011-08-30 10:50:12 +0200, Stefano Sabatini encoded: [...] Updated with misc cosmetics for improving readability, I'll apply soon if I read no comments. -- FFmpeg = Fascinating and Forgiving Magical Pacific Evangelical God
From 9c00b7e9eed542938273b81f70dc0bb7d6d2d45e Mon Sep 17 00:00:00 2001 From: Stefano Sabatini <stefano.sabatini-lala@poste.it> Date: Sat, 25 Jun 2011 13:06:24 +0200 Subject: [PATCH] lavfi: port tinterlace filter from MPlayer
Port MPlayer tinterlace filter from MPlayer, with some ideas taken from the FFmbc/libavfilter port, with the following main differences: [...] --- a/doc/filters.texi +++ b/doc/filters.texi @@ -2420,6 +2420,41 @@ Complete example of a thumbnail creation with @command{ffmpeg}: ffmpeg -i in.avi -vf thumbnail,scale=300:200 -frames:v 1 out.png @end example
+@section tinterlace + +Perform temporal field interlacing - merge pairs of frames into an +interlaced frame, halving the framerate. Even frames are moved into +the upper field, odd frames to the lower field. +
+The frames are counted starting from 1, so the first input frame is +considered odd.
This is a little inconsistent with the convenction used in showinfo, which counts frames starting from 0...
+ +This filter accepts a parameter specifying the mode. Available modes +are: + +@table @samp +@item 0 +Move odd frames into the upper field of the new frame, even into the +lower field, generating a double height frame at half framerate. +
+@item 1 +Only output odd frames, even frames are dropped, generating a frame with +unchanged height at half framerate. + +@item 2 +Only output even frames, odd frames are dropped, generating a frame with +unchanged height at half framerate.
I previously copied this description from the MPlayer manual, but looks wrong to me, indeed in libmpcodecs we have: case 1: if (vf->priv->frame & 1) ret = vf_next_put_image(vf, mpi, MP_NOPTS_VALUE); break; case 2: if ((vf->priv->frame & 1) == 0) ret = vf_next_put_image(vf, mpi, MP_NOPTS_VALUE); break; For case 1, apparently we have odd frame -> output, but frame starts from 0. I fixed the docs accordingly (since I want to keep the two filters equivalent), if I'm right the MPlayer manual should be fixed accordingly. -- FFmpeg = Fancy Friendly Majestic Puritan Encoding/decoding Guru
On date Saturday 2011-12-31 01:14:59 +0100, Stefano Sabatini encoded:
On date Tuesday 2011-12-27 13:08:52 +0100, Stefano Sabatini encoded:
On date Tuesday 2011-08-30 10:50:12 +0200, Stefano Sabatini encoded: [...] Updated with misc cosmetics for improving readability, I'll apply soon if I read no comments. -- FFmpeg = Fascinating and Forgiving Magical Pacific Evangelical God
From 9c00b7e9eed542938273b81f70dc0bb7d6d2d45e Mon Sep 17 00:00:00 2001 From: Stefano Sabatini <stefano.sabatini-lala@poste.it> Date: Sat, 25 Jun 2011 13:06:24 +0200 Subject: [PATCH] lavfi: port tinterlace filter from MPlayer
Port MPlayer tinterlace filter from MPlayer, with some ideas taken from the FFmbc/libavfilter port, with the following main differences: [...] --- a/doc/filters.texi +++ b/doc/filters.texi @@ -2420,6 +2420,41 @@ Complete example of a thumbnail creation with @command{ffmpeg}: ffmpeg -i in.avi -vf thumbnail,scale=300:200 -frames:v 1 out.png @end example
+@section tinterlace + +Perform temporal field interlacing - merge pairs of frames into an +interlaced frame, halving the framerate. Even frames are moved into +the upper field, odd frames to the lower field. +
+The frames are counted starting from 1, so the first input frame is +considered odd.
This is a little inconsistent with the convenction used in showinfo, which counts frames starting from 0...
+ +This filter accepts a parameter specifying the mode. Available modes +are: + +@table @samp +@item 0 +Move odd frames into the upper field of the new frame, even into the +lower field, generating a double height frame at half framerate. +
+@item 1 +Only output odd frames, even frames are dropped, generating a frame with +unchanged height at half framerate. + +@item 2 +Only output even frames, odd frames are dropped, generating a frame with +unchanged height at half framerate.
I previously copied this description from the MPlayer manual, but looks wrong to me, indeed in libmpcodecs we have:
case 1: if (vf->priv->frame & 1) ret = vf_next_put_image(vf, mpi, MP_NOPTS_VALUE); break; case 2: if ((vf->priv->frame & 1) == 0) ret = vf_next_put_image(vf, mpi, MP_NOPTS_VALUE); break;
For case 1, apparently we have odd frame -> output, but frame starts from 0.
I fixed the docs accordingly (since I want to keep the two filters equivalent), if I'm right the MPlayer manual should be fixed accordingly. -- FFmpeg = Fancy Friendly Majestic Puritan Encoding/decoding Guru
From 26020ec55c4373e6088e6f96a8dfcd803c69a1b9 Mon Sep 17 00:00:00 2001 From: Stefano Sabatini <stefano.sabatini-lala@poste.it> Date: Sat, 25 Jun 2011 13:06:24 +0200 Subject: [PATCH] lavfi: port tinterlace filter from MPlayer
Port MPlayer tinterlace filter from MPlayer, with some ideas taken from the FFmbc/libavfilter port, with the following main differences:
* added support for full-scale YUVJ formats * added support for YUVA420P * request_frame() on the filter is forced to return a frame * some code factorization (related to the copy_picture_fields() function) * fixed black padding values for mode 3 --- Changelog | 1 + configure | 1 + doc/filters.texi | 34 +++++ libavfilter/Makefile | 1 + libavfilter/allfilters.c | 1 + libavfilter/vf_tinterlace.c | 325 +++++++++++++++++++++++++++++++++++++++++++ 6 files changed, 363 insertions(+), 0 deletions(-) create mode 100644 libavfilter/vf_tinterlace.c
Pushed. -- FFmpeg = Forgiving Foolish Magnificient Purposeless EnGine
On date Saturday 2011-12-31 11:48:48 +0100, Stefano Sabatini encoded:
On date Saturday 2011-12-31 01:14:59 +0100, Stefano Sabatini encoded: [...]
From 26020ec55c4373e6088e6f96a8dfcd803c69a1b9 Mon Sep 17 00:00:00 2001 From: Stefano Sabatini <stefano.sabatini-lala@poste.it> Date: Sat, 25 Jun 2011 13:06:24 +0200 Subject: [PATCH] lavfi: port tinterlace filter from MPlayer
Port MPlayer tinterlace filter from MPlayer, with some ideas taken from the FFmbc/libavfilter port, with the following main differences:
* added support for full-scale YUVJ formats * added support for YUVA420P * request_frame() on the filter is forced to return a frame * some code factorization (related to the copy_picture_fields() function) * fixed black padding values for mode 3 --- Changelog | 1 + configure | 1 + doc/filters.texi | 34 +++++ libavfilter/Makefile | 1 + libavfilter/allfilters.c | 1 + libavfilter/vf_tinterlace.c | 325 +++++++++++++++++++++++++++++++++++++++++++ 6 files changed, 363 insertions(+), 0 deletions(-) create mode 100644 libavfilter/vf_tinterlace.c
Pushed.
BTW what should we do with the libmpcodecs tinterlace filter (which is not properly transmitting timestamps)? Should we keep it or dump it? -- FFmpeg = Funny & Faithless Mere Portentous EntanGlement
On Sun, Jan 01, 2012 at 04:23:25PM +0100, Stefano Sabatini wrote:
On date Saturday 2011-12-31 11:48:48 +0100, Stefano Sabatini encoded:
On date Saturday 2011-12-31 01:14:59 +0100, Stefano Sabatini encoded: [...]
From 26020ec55c4373e6088e6f96a8dfcd803c69a1b9 Mon Sep 17 00:00:00 2001 From: Stefano Sabatini <stefano.sabatini-lala@poste.it> Date: Sat, 25 Jun 2011 13:06:24 +0200 Subject: [PATCH] lavfi: port tinterlace filter from MPlayer
Port MPlayer tinterlace filter from MPlayer, with some ideas taken from the FFmbc/libavfilter port, with the following main differences:
* added support for full-scale YUVJ formats * added support for YUVA420P * request_frame() on the filter is forced to return a frame * some code factorization (related to the copy_picture_fields() function) * fixed black padding values for mode 3 --- Changelog | 1 + configure | 1 + doc/filters.texi | 34 +++++ libavfilter/Makefile | 1 + libavfilter/allfilters.c | 1 + libavfilter/vf_tinterlace.c | 325 +++++++++++++++++++++++++++++++++++++++++++ 6 files changed, 363 insertions(+), 0 deletions(-) create mode 100644 libavfilter/vf_tinterlace.c
Pushed.
BTW what should we do with the libmpcodecs tinterlace filter (which is not properly transmitting timestamps)?
Should we keep it or dump it?
if the new one supports all features of the old and is the same speed or faster. then i think thats clear, drop the old/buggy one [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Many things microsoft did are stupid, but not doing something just because microsoft did it is even more stupid. If everything ms did were stupid they would be bankrupt already.
On 27/06/11 22:49, Stefano Sabatini wrote: [...] Baptiste has already done this for FFmbc. -- Mark
On 29/06/11 10:48, Mark Himsley wrote:
On 27/06/11 22:49, Stefano Sabatini wrote:
[...]
Baptiste has already done this for FFmbc.
Sorry - ignore me, I hadn't spotted how old this thread originally was. -- Mark
On date Wednesday 2011-06-29 10:48:37 +0100, Mark Himsley encoded:
On 27/06/11 22:49, Stefano Sabatini wrote:
[...]
Baptiste has already done this for FFmbc.
Indeed I explicitely used some of his code. -- FFmpeg = Furious and Free Mythic Picky Everlasting God
participants (9)
-
Alexander Strasser -
Ivan Kalvachev -
Maksym Veremeyenko -
Mark Himsley -
Michael Niedermayer -
michaelni＠gmx.at
-
Stefano Sabatini -
Stefano Sabatini -
stefano.sabatini-lala＠poste.it