Re: [FFmpeg-soc] libavfilter FT new FFmpeg maintainership

[Stefano Sabatini]

On date Friday 2011-01-21 15:12:35 +0100, Thilo Borgmann encoded:
> Am 21.01.11 14:58, schrieb Maksym Veremeyenko:
> > Thilo Borgmann написав(ла):
> > [...]
> >> Although submission standards are also discussed (or changed) these days, 
> >> it
> >> doesn't mean that the acceptance of more parts of the filter soc repo has
> >> anything to with who has worked on it or who will post it nor who will be
> >> reviewing or committing it.
> 
> > most libavfilter commits was by *stefano* is he is not maintainer now...
> 
> As I said it doesn't matter what name will have done the work with, or review,
> or commit, or maintain the corresponding parts.

I consider the libavfilter soc repo *deprecated*, I updated the
libavfilter soc to the last SVN revision and I don't think that I'll
update it anymore.

I plan to post an updated patch for the movie source (which is maybe
the most requested feature at the moment) and possibly apply it to the
repository where I still have commit rights, then I don't know which
will be the relationship between the videolan and the git.ffmpeg.org
repo and how they will be synched.

As for the soc filters, most of them have been already discussed for
inclusions, resuming:

* rotate: the last patch I posted has still many problems, and I
  wanted to take a deeper look at it, then my focus switched on other
  things.

* movie: as I said, I hope to be able to commit it soon

* split: the last time I tried there was still some problem with the
  pad/crop/negate interactions, and more framework changes are
  required for the auto-insertion of fifo filters when required, see
  comments from Michael

* drawtext: misses anti-aliasing, currently the quality of overlayed
  non anti-aliased fonts is crappy

* negate: it should be implemented by using a more general lut filter, 
  work-in-progress patch published by me on ffmpeg-devel, then again
  my focus and priority switched to something else

* fade, fps: never discussed for integration, though their cleanup
  should be quite easy

New filters should be discussed on ffmpeg-devel, we could eventully
decide to create a new branch/repo for experimental stuff (mildly
against this idea, I'd rather prefer to directly work for integration
in one of the "official" repos).

Maintainership status: Vitor is the nominal maintainer of the
libavfilter soc repo, Michael is the maintainer of libavfilter in the
videolan repo, I did most of the coding work but I rely a lot on
Michael for design issues (and he's imho right now the only one with
the required competence, interest and knowledge for evaluating them).

libavfilter audio is a work in progress, the recently patches posted
on ffmpeg-devel work almost fine, but there is still a bug I need to
fix before to update them again.

Best regards.
___
FFmpeg-soc mailing list
FFmpeg-soc@mplayerhq.hu
https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc

Re: [FFmpeg-soc] [soc]: r5931 - libavfilter/vf_fade.c

[Stefano Sabatini]

On date Tuesday 2010-09-07 22:49:24 +0200, bcoudurier encoded:
> Author: bcoudurier
> Date: Tue Sep  7 22:49:24 2010
> New Revision: 5931
> 
> Log:
> Fix fade filter with 4:2:0 input, h must not be divided since i is already 
> divided below
> 
> Modified:
>libavfilter/vf_fade.c
> 
> Modified: libavfilter/vf_fade.c
> ==
> --- libavfilter/vf_fade.c Tue Aug 24 11:02:54 2010(r5930)
> +++ libavfilter/vf_fade.c Tue Sep  7 22:49:24 2010(r5931)
> @@ -153,7 +153,7 @@ static void draw_slice(AVFilterLink *lin
>  if (outpic->data[0] && outpic->data[1]) {
>  /* chroma planes */
>  for (plane = 1; plane < 3; plane++) {
> -for (i = 0; i < h >> fade->vsub; i++) {
> +for (i = 0; i < h; i++) {
>  p = outpic->data[plane] + ((y+i) >> fade->vsub) * 
> outpic->linesize[plane];
>  for (j = 0; j < link->w >> fade->hsub; j++) {
>  /* 8421367 = ((128 << 1) + 1) << 15. It is an integer

Is something preventing this filter from main SVN application (after
publication and discussion on ffmpeg-devel of course)?

Regards.
___
FFmpeg-soc mailing list
FFmpeg-soc@mplayerhq.hu
https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc

Re: [FFmpeg-soc] [PATCH] Add af sox - lavfi wrapper for libsox

[Stefano Sabatini]

On date Thursday 2010-09-02 01:11:21 -0700, S.N. Hemanth Meenakshisundaram 
encoded:
> Hi All,
> 
> I need some advice on the lavfi audio sox wrapper filter.
> 
> The sox API that starts off the filtering of data - sox_flow_effects() -
> keeps trying to pull data from the input effect defined in lavfi until
> it sends EOF, otherwise doesn't return. So I changed the af_sox input
> effect behavior in the patch below to always send EOF after giving every
> buffer to the sox chain. This means the sox chain would be reinitialized
> when calling sox_flow_effects for each audio buffer. This causes sox to
> crash after playing out a few buffers.
> 
> Instead, would it be ok to call sox_flow_effects once in a new thread
> and let it fetch and output its buffers from/to the FIFOs at the input
> and output? Please let me know.

If this is the supposed way to use libsox then it's OK. For maximum
portability you may use pthreads.

> Regards,
> 
> ---
>  libavfilter/Makefile |1 +
>  libavfilter/af_sox.c |  351 
> ++
>  libavfilter/allfilters.c |1 +

Missing configure magic (yes it should go in the same patch).

>  3 files changed, 353 insertions(+), 0 deletions(-)
>  create mode 100644 libavfilter/af_sox.c

> diff --git a/libavfilter/Makefile b/libavfilter/Makefile
> index fe8b4db..749fbcc 100644
> --- a/libavfilter/Makefile
> +++ b/libavfilter/Makefile
> @@ -16,6 +16,7 @@ OBJS = allfilters.o 
> \
>  
>  OBJS-$(CONFIG_ANULL_FILTER)  += af_anull.o
>  OBJS-$(CONFIG_RESAMPLE_FILTER)   += af_resample.o
> +OBJS-$(CONFIG_SOX_FILTER)+= af_sox.o
>  
>  OBJS-$(CONFIG_ASPECT_FILTER) += vf_aspect.o
>  OBJS-$(CONFIG_CROP_FILTER)   += vf_crop.o
> diff --git a/libavfilter/af_sox.c b/libavfilter/af_sox.c
> new file mode 100644
> index 000..383958a
> --- /dev/null
> +++ b/libavfilter/af_sox.c
> @@ -0,0 +1,351 @@
[...]
> +/**
> + * @file
> + * Sox Filter
> + */
> +
> +#include "avfilter.h"
> +#include "parseutils.h"
> +#include "libavcodec/audioconvert.h"
> +#include "libavutil/fifo.h"
> +#include 
> +#include 
> +#include 
> +
> +typedef struct {
> +char *sox_args;  ///< filter arguments;
> +sox_effects_chain_t * chain; ///< handle to sox effects chain.

Nit: *chain

> +AVFifoBuffer *in_fifo;   ///< fifo buffer of input audio frame 
> pointers
> +AVFifoBuffer *out_fifo;  ///< fifo buffer of output audio data from 
> sox
> +int64_t ch_layout;   ///< channel layout of data handled
> +int64_t sample_rate; ///< sample rate of data handled
> +int nb_channels; ///< number of channels in our channel 
> layout

Nit: channels_nb

I prefer the _nb at the end because I read it as:
channels number
rather than
number of channels

also having _nb at the end permits alignment tricks like:
args
args_nb

> +int out_size;///< desired size of each output audio 
> buffer
> +} SoxContext;
> +
> +static int query_formats(AVFilterContext *ctx)
> +{
> +// Sox effects only operate on signed 32-bit integer audio data.
> +enum SampleFormat sample_fmts[] = {
> +SAMPLE_FMT_S32, SAMPLE_FMT_NONE
> +};
> +
> +avfilter_set_common_formats(ctx, avfilter_make_format_list(sample_fmts));
> +return 0;
> +}
> +
> +typedef struct {
> +SoxContext *lavfi_ctx;
> +} sox_inout_ctx;
> +
> +// configures the sox effect for sample input.
> +static int inout_config_opts(sox_effect_t *effect, int argc, char **argv)
> +{
> +SoxContext *sox;
> +if (argc < 2) {
> +lsx_fail("lavfi context not supplied");

> +return (SOX_EOF);

unnecessary ()

> +}
> +sscanf(argv[1], "%ld", (long int *)&sox);
> +((sox_inout_ctx *)effect->priv)->lavfi_ctx = sox;
> +return SOX_SUCCESS;
> +}
> +
> +/**
> + * a sox effect handler to handle input of samples to the effects chain.

Please describe what the function *does*, not what the function
*is*. That is, use a predicate (start with a verb) rather than a
nominal form.

> + * The function that will be called to input samples into the effects chain.
> + */
> +static int input_drain(sox_effect_t *effect,
> +   sox_sample_t *o_samples, size_t *o_samples_size)
> +{
> +
> +SoxContext *sox = ((sox_inout_ctx *)effect->priv)->lavfi_ctx;
> +AVFilterBufferRef *samplesref;
> +int input_nb_samples = 0;
> +
> +if (av_fifo_size(sox->in_fifo)) {
> +
> +// read first audio frame from queued input buffers and give it to 
> sox.
> +av_fifo_generic_read(sox->in_fifo, &samplesref, sizeof(samplesref), 
> NULL);
> +
> +/**
> + * inside lavfi, nb_samples is number of samples in each channel, 
> while in sox
> + * number of samples refers to the total number over all channels
> + */
> +input_nb_samples = samplesref->audio->samples_nb * s

Re: [FFmpeg-soc] [PATCH] Add af_sox - sox effects library wrapper

[Stefano Sabatini]

On date Thursday 2010-08-19 04:38:44 -0700, S.N. Hemanth Meenakshisundaram 
encoded:
> Modified so that request frame has default behaviour - passes it on to
> previous filter in chain.
> Output, if any is available with the output fifo, is now pushed to next
> filter within filter samples itself after it has added input data to the
> input fifo.
> 
> Now the command:
> 
> ./ffplay -af sox=flanger crashes within sox due to some uninitialized
> parameter of the effect. Will post an update once I get the config right.
> 
> Also, should the configure magic for this filter be part of this patch
> or a separate one.

In this one, also please add a filters.texi entry.

Regards.
___
FFmpeg-soc mailing list
FFmpeg-soc@mplayerhq.hu
https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc

Re: [FFmpeg-soc] [PATCH] Auto insert resample filter between audio filters during sample format negotiation

[Stefano Sabatini]

On date Monday 2010-08-16 01:07:19 -0700, S.N. Hemanth Meenakshisundaram 
encoded:
> 
> Inserts resample filter between audio filters with incompatible formats.
> Updated as per Michael's comment earlier.
> Doesn't work in some cases due to a separate issue with lavfi
> framework's merge_formats function. Will post a patch for that when its
> fixed.
> 
> ---
>  libavfilter/avfiltergraph.c |   16 
>  1 files changed, 12 insertions(+), 4 deletions(-)
> 
> 
> 

> diff --git a/libavfilter/avfiltergraph.c b/libavfilter/avfiltergraph.c
> index 2123c28..ef13bbf 100644
> --- a/libavfilter/avfiltergraph.c
> +++ b/libavfilter/avfiltergraph.c
> @@ -128,14 +128,22 @@ static int query_formats(AVFilterGraph *graph, AVClass 
> *log_ctx)
>  if(link && link->in_formats != link->out_formats) {
>  if(!avfilter_merge_formats(link->in_formats,
> link->out_formats)) {
> +enum AVMediaType type = link->type;
>  AVFilterContext *scale;
>  char scale_args[256];
>  /* couldn't merge format lists. auto-insert scale filter 
> */
> -snprintf(inst_name, sizeof(inst_name), "auto-inserted 
> scaler %d",
> - scaler_count++);
> -avfilter_open(&scale, avfilter_get_by_name("scale"), 
> inst_name);
> +const char *filt_name = type == AVMEDIA_TYPE_VIDEO ? 
> "scale" : "resample";
> +snprintf(inst_name, sizeof(inst_name), "auto-inserted 
> %sr %d",
> + filt_name, scaler_count++);
> +avfilter_open(&scale, 
> avfilter_get_by_name(filt_name),inst_name);
> +
> +if (type == AVMEDIA_TYPE_VIDEO)
> +snprintf(scale_args, sizeof(scale_args), "0:0:%s",
> + graph->scale_sws_opts);
> +if (type == AVMEDIA_TYPE_AUDIO)
> +snprintf(scale_args, sizeof(scale_args), "%d:-1",
> + link->out_formats->formats[0]);
>  
> -snprintf(scale_args, sizeof(scale_args), "0:0:%s", 
> graph->scale_sws_opts);
>  if(!scale || scale->filter->init(scale, scale_args, 
> NULL) ||
>   avfilter_insert_filter(link, scale, 0, 0)) {
>  avfilter_destroy(scale);

Looks OK. I'll apply it as the audio lavfi framework patch will be
applied.

Regards.
___
FFmpeg-soc mailing list
FFmpeg-soc@mplayerhq.hu
https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc

Re: [FFmpeg-soc] [soc] libavsequencer [PATCH 02/08] Sub-song public API header file.

[Stefano Sabatini]

On date Sunday 2010-08-15 19:35:14 +0200, Vitor Sessak encoded:
> On 08/15/2010 06:41 PM, Sebastian Vater wrote:
> >Vitor Sessak a écrit :
> >>On 08/14/2010 02:50 PM, Sebastian Vater wrote:
> >>
> >>>Up to now, they're distinct entities, sub-volume and sub-panning is only
> >>>considered during slides but never actually taken into account on final
> >>>calculation.
> >>>
> >>>This stuff will surely cause interesting discussions. Or to be short,
> >>>yes, there's a lot of things to improve! But all this please, when the
> >>>basic stuff here works, i.e. module playback as original TuComposer did.
> >>>[...]
> >>>Well, removing this would not actually be a problem, because I never
> >>>used that, in TuComposer all loaders, indeed, have a flag to tell if to
> >>>use 8-bit or 6-bit volumes, but my current implementation always used
> >>>8-bit though.
> >>>
> >>>Maybe this is really a candidate to fully remove.
> >>
> >>Everything that is not used by any code _should_ be fully removed! It
> >>is easy to start simple and improve afterwards than to try to commit a
> >>complicated patch with unused parts.
> >
> >It is used by the player, i.e. the player handles 6-bit volumes when
> >this flag is set. I also remembered somethings which makes it impossible
> >to replace this without getting trouble (synth sound support).
> >The synth sound assembler also uses 6-bit in that case and since this a
> >full-featured assembly language, it's practically impossible to convert
> >TCM files correctly to 8-bit instead. :(
> 
> What about other file formats?
> 
> >In TuComposer the user was able to put a parameter for the demuxers
> >which decides to use original 6-bit or 8-bit volume. The current demuxer
> >in FFmpeg, however doesn't allow this now, but it might encounter a file
> >which already has this flag set.
> >
> >>>
> >>>No, it requires fully understanding of what's being parsed. Again, this
> >>>is hard to describe in words (this problem was detected after
> >>>disassembly nightmares almost 10 years ago, so I barely remember what
> >>>was the exact cause for this flag, now).
> >>>
> >>>Let me explain the problem:
> >>>In XM/IT when you use the global volume/panning commands, they only
> >>>affect the next note being played, but not in S3M, here it affects all
> >>>notes being currently played already!
> >>
> >>Then it looks clear to me to duplicate all the volume formats to have
> >>an "immediate" version and a "next note" version. Do you agree?
> >
> >Which is much more complex and more code than just defining a new flag.
> >
> >>Let me repeat my question again: Why is the stack depth should be
> >>described in the BSS? Why not set it in player.h?
> >
> >player.h is read-only for composers and external users, i.e. anything
> >that will go there isn't user editable anymore and this flag is supposed
> >to be user editable.
> 
> So you need something that is both user-editable and not part of the
> BSS. Again, where should be stuff that is not part of the
> description of a song _and_ is set by the user?
> 
> >The other point was your idea with moving the actual stack data to
> >player.h, that was an excellent idea, because this is not supposed to be
> >writeable to the end-user.
> >>>The BSS should not pass actually data to the player which it can't
> >>>handle,
> >>
> >>No, of course it should! How can the BSS avoid doing it if it is not
> >>supposed to know anything about the player? If the players limitations
> >>should be defined somewhere, it should be in player.h!
> >
> >The player itself can also play more than 256 channels, in fact it is a
> >limitation of both the player and the BSS (the track limitations and
> >effect limitations are accounting for the BSS, too).
> 
> So where the limitation would be if we change the BSS to a int16_t
> (no, I don't think this has any use doing it, but you understand my
> point)?
> 
> What it looks like to me you are doing is:
> 
> 1- You have some BSS parameter foo.
> 2- Sane values for the parameter foo is between 0 and AA
> 3- You look for the integer type whose maximum value is closest to AA
> 4- You use this type for foo.
> 
> I don't think this is the cleaner neither the most future-proof way
> of determining sane values for fields.
> 
> >>>and more than 8-bit channels is not handled correctly, it will
> >>>fallback a lots of features normally available, i.e. exact channel
> >>>control via effects.
> >>>
> >>>The engines itself don't care much about numbers actually there, in
> >>>theory both the module virtual channels and song host channels can
> >>>handle infinite channels.
> >>>
> >>>But the effects are designed to access and control them, also, which is
> >>>done currently by 8-bit values (other 8-bit decide control mechanism).
> >>>But I do expect, as a musician that I can control what I play.
> >>
> >>Again, what the player can or cannot do is completely irrelevant for
> >>the discussion of the BSS. The BSS should be a way to describe a song,
> >>no matter who (or

Re: [FFmpeg-soc] [PATCH] Add af_sox initial draft

[Stefano Sabatini]

On date Sunday 2010-08-15 00:05:07 -0700, S.N. Hemanth Meenakshisundaram 
encoded:
> 
> Sox wrapper for lavfi:
> 
> 1. sox internally uses only integer 32-bit signed format for all its
> effects. It can convert to S32 if other format inputs are supplied but I
> guess we would want to do any such conversions internally (using
> inserted resample filter) and only send s32 data to sox?

Yes.
 
> 2. sox reads data from an 'input handler' effect in af_sox that forms
> the first effect of the chain and writes data out to last effect
> 'output_handler' again defined in af_sox. Unfortunately, it does not
> guarantee when an input will be processed and output. Also inserting x
> samples need not mean all of them will be processed together. Hence the
> current design is as follows:
> 
> i. i/p is assumed to be s32 (achieved with a resample filter inserted
> ahead) and o/p is also changed to other formats if necessary by another
> af_resample. The resample filter will also serve to keep channels constant.
> 
> ii. The effects chain (including input and output handlers) is built and
> configured during init.
> 
> iii. Incoming s32 samples (coming in via filter samples) are added to an
> input fifo.
> 
> iv. When sox requests data through its 'input handler' effect, we pull
> data from the fifo and copy it into the buffer provided by sox for input.
> 
> v. When sox outputs any data, we queue it to an output fifo.
> 
> vi. When the next lavfi filter calls request_frame, we create a lavfi
> audio buffer of predetermined size and copy data from the output fifo
> into it and pass it on to the next filter.

Looks fine.

If I understood it correctly so we have this design:
[lavfi input fifo] [sox input handler] [sox effects] [sox output handler] 
[lavfi output fifo]

> Please review code and comment on the design as well. I will post
> updates as I make more changes.
> 
> Regards,
> 
> ---
>  libavfilter/Makefile |1 +
>  libavfilter/af_sox.c |  323 
> ++
>  libavfilter/allfilters.c |1 +
>  3 files changed, 325 insertions(+), 0 deletions(-)
>  create mode 100644 libavfilter/af_sox.c

Please add the required configure magic, for examples check the
drawtext filter or the opencv filter I recently posted on devel.

> diff --git a/libavfilter/Makefile b/libavfilter/Makefile
> index 920f428..4c4ec74 100644
> --- a/libavfilter/Makefile
> +++ b/libavfilter/Makefile
> @@ -17,6 +17,7 @@ OBJS = allfilters.o 
> \
>  OBJS-$(CONFIG_AFIFO_FILTER)  += af_afifo.o
>  OBJS-$(CONFIG_NULLAUD_FILTER)+= af_nullaud.o
>  OBJS-$(CONFIG_ASPLIT_FILTER) += af_asplit.o
> +OBJS-$(CONFIG_SOX_FILTER)+= af_sox.o
>  
>  OBJS-$(CONFIG_ASPECT_FILTER) += vf_aspect.o
>  OBJS-$(CONFIG_CROP_FILTER)   += vf_crop.o
> diff --git a/libavfilter/af_sox.c b/libavfilter/af_sox.c
> new file mode 100644
> index 000..eb1b8aa
> --- /dev/null
> +++ b/libavfilter/af_sox.c
> @@ -0,0 +1,323 @@
> +/*
> + * copyright (c) 2010 S.N. Hemanth Meenakshisundaram
> + *
> + * 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
> + */
> +
> +/**
> + * @file
> + * Sox Filter
> + */
> +
> +#include "avfilter.h"
> +#include "libavcodec/audioconvert.h"
> +#include "libavutil/fifo.h"
> +#include 
> +#include 
> +
> +typedef struct {
> +sox_effects_chain_t * chain; ///< handle to sox effects chain.
> +AVFifoBuffer *in_fifo;   ///< fifo buffer of input audio frame 
> pointers
> +AVFifoBuffer *out_fifo;  ///< fifo buffer of output audio data from 
> sox
> +int64_t ch_layout;   ///< channel layout of data handled
> +int nb_channels; ///< number of channels in our channel 
> layout
> +int out_size;///< desired size of each output audio 
> buffer
> +} SoxContext;
> +
> +static int query_formats(AVFilterContext *ctx)
> +{
> +// Sox effects only operate on signed 32-bit integer audio data.
> +enum SampleFormat sample_fmts[] = {
> +SAMPLE_FMT_S32, PIX_FMT_NONE
> +};
> +
> +avfilter_set_common_formats(ctx, avfilter_make_format_list(sample_fmts));
> +return 0;
> +}
> +
>

Re: [FFmpeg-soc] [soc] G.723.1 Encoder: Encoder wireframe + highpass filter

[Stefano Sabatini]

On date Wednesday 2010-08-11 22:05:02 +0530, Mohamed Naufal encoded:
> ---
>  libavcodec/Makefile|1 +
>  libavcodec/allcodecs.c |2 +-
>  libavcodec/g723_1.c|   68 
> 
>  3 files changed, 70 insertions(+), 1 deletions(-)
[...]
> --- a/libavcodec/g723_1.c
> +++ b/libavcodec/g723_1.c
> @@ -1075,3 +1075,71 @@ AVCodec g723_1_decoder = {
>  .long_name  = NULL_IF_CONFIG_SMALL("G.723.1"),
>  .capabilities   = CODEC_CAP_SUBFRAMES,
>  };
> +
> +#if CONFIG_G723_1_ENCODER
> +static av_cold int g723_1_encode_init(AVCodecContext *avctx)
> +{
> +G723_1_Context *p = avctx->priv_data;
> +
> +if (avctx->sample_rate != 8000) {
> +av_log(avctx, AV_LOG_ERROR, "Only 8000Hz sample rate supported\n");
> +return -1;
> +}
> +
> +if (avctx->channels != 1) {
> +av_log(avctx, AV_LOG_ERROR, "Only mono supported\n");
> +return -1;
> +}
> +
> +if (avctx->bit_rate == 6300) {
> +p->cur_rate = Rate6k3;
> +} else if (avctx->bit_rate == 5300) {
> +p->cur_rate = Rate5k3;
> +} else {
> +av_log(avctx, AV_LOG_ERROR,
> +   "Bitrate not supported, use either 5.3k or 6.3k\n");
> +return -1;

Uhm, please use AVERROR(EINVAL)/AVERROR_PATCHWELCOME rather than -1.

Regards.
___
FFmpeg-soc mailing list
FFmpeg-soc@mplayerhq.hu
https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc

Re: [FFmpeg-soc] [PATCH] Rename pic fields in AVFilterLink to buf

[Stefano Sabatini]

On date Wednesday 2010-08-04 14:10:37 +0200, Michael Niedermayer encoded:
> On Mon, Aug 02, 2010 at 11:09:40AM +0200, Stefano Sabatini wrote:
> > On date Monday 2010-08-02 00:58:54 -0700, S.N. Hemanth Meenakshisundaram 
> > encoded:
> > > ---
> > > 
> > >  ffmpeg.c |4 ++--
> > >  ffplay.c |4 ++--
> > >  libavfilter/avfilter.c   |   34 +-
> > >  libavfilter/avfilter.h   |6 +++---
> > >  libavfilter/defaults.c   |   16 
> > >  libavfilter/vf_drawbox.c |2 +-
> > >  libavfilter/vf_drawtext.c|2 +-
> > >  libavfilter/vf_fade.c|6 +++---
> > >  libavfilter/vf_hflip.c   |4 ++--
> > >  libavfilter/vf_negate.c  |4 ++--
> > >  libavfilter/vf_pad.c |8 
> > >  libavfilter/vf_pixdesctest.c |8 
> > >  libavfilter/vf_rotate.c  |   18 +-
> > >  libavfilter/vf_scale.c   |8 
> > >  libavfilter/vf_split.c   |2 +-
> > >  libavfilter/vf_transpose.c   |   18 +-
> > >  libavfilter/vf_unsharp.c |4 ++--
> > >  17 files changed, 74 insertions(+), 74 deletions(-)
> > 
> > Looks fine.
> > 
> > As for the other patches, we have to wait for Michael explicit
> > approval, then I'll commit the patches to FFmpeg SVN.
> 
> the renames should all be fine if they do nothing but rename

All applied with a minor variant:
avfilter_copy_picref_props -> avfilter_copy_buffer_ref_props
rather than:  avfilter_copy_bufref_props

for consistency reasons.

Regards.
___
FFmpeg-soc mailing list
FFmpeg-soc@mplayerhq.hu
https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc

Re: [FFmpeg-soc] [PATCH] Move format from AVFilterBuffer to AVFilterPicRef

[Stefano Sabatini]

On date Friday 2010-08-06 10:21:42 -0700, S.N. Hemanth Meenakshisundaram 
encoded:
> 
> > > On Sun, Aug 01, 2010 at 11:41:09PM -0700, S.N. Hemanth
> Meenakshisundaram wrote:
> > > >  ffplay.c  |8 
> > > >  libavfilter/avfilter.h|2 +-
> > > >  libavfilter/defaults.c|8 
> > > >  libavfilter/vf_overlay.c  |   12 ++--
> > > >  libavfilter/vsrc_buffer.c |2 +-
> > > >  libavfilter/vsrc_movie.c  |2 +-
> > > >  6 files changed, 17 insertions(+), 17 deletions(-)
> > > > 415376236550b0dd86fe180594d1f65f9d9d077f 
> 0001-Move-format-from-AVFilterBuffer-to-AVFilterPicRef.patch
> > >
> > > looks ok if tested
> 
> > This is causing regressions here.
> 
> > Hemanth, can you check it?
> 
> Hi Stefano,
> 
> The regression was being caused by my previous patch to resize
> AVFilterBuffer's data and linesize arrays to 8. Strangely, the errors only
> show up in make test after applying the current patch.
> 
> Applying the attached fix and then the current patch will solve the issue
> and make test passes. I had only tested with make lavfitest and so missed
> this. Will test with 'make test' too in the future.
> 
> Also, this bug fix will no longer be needed once the later patch to resize
> AVFilterBufferRef itself is applied.
> 
> Regards,
> Hemanth

> --- a/libavfilter/defaults.c
> +++ b/libavfilter/defaults.c
> @@ -59,8 +59,8 @@
>  // SIMD-friendly
>  av_fill_image_pointers(pic->data, pic->format, ref->h, buf, 
> pic->linesize);
>  
> -memcpy(ref->data, pic->data, sizeof(pic->data));
> -memcpy(ref->linesize, pic->linesize, sizeof(pic->linesize));
> +memcpy(ref->data, pic->data, 4*sizeof(pic->data[0]));
> +memcpy(ref->linesize, pic->linesize, 4*sizeof(pic->linesize[0]));
>  
>  return ref;

Both applied.
___
FFmpeg-soc mailing list
FFmpeg-soc@mplayerhq.hu
https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc

Re: [FFmpeg-soc] [PATCH] Audio visualization initial draft (incomplete) and question on callbacks

[Stefano Sabatini]

On date Friday 2010-08-06 02:57:55 -0700, S.N. Hemanth Meenakshisundaram 
encoded:
> 
> This filter will need the value of delay (calculated in ffplay based on
> how much SDL has consumed at the moment. What would be the best way to
> get this information to the filter? I was thinking of using a callback
> but am not sure if its right to call an ffplay.c function from lavfi.
> Please let me know if this is ok or if there are better ways.

You can put the callback in the opaque, then it would be a job of the
framework to correctly fill the opaque when inserting the filter.

Also ideally we should have a unique filterchain mixing audio and
video, since that requires much more framework changes than doesn't
look like a viable solution right now.

One problem that I see with this approach is that the function
callback may need to access the ffplay context, which is defined
statically in ffplay.c.
 
> I already get audio info through filter_samples and other info through
> init. Only changing information from video side is a problem.
> 
> Regards,
> Hemanth
> 
> ---
>  libavfilter/af_aviz.c |  235 
> +
>  1 files changed, 235 insertions(+), 0 deletions(-)
>  create mode 100644 libavfilter/af_aviz.c
> 
> 
> 

> diff --git a/libavfilter/af_aviz.c b/libavfilter/af_aviz.c
> new file mode 100644
> index 000..1dd77ca
> --- /dev/null
> +++ b/libavfilter/af_aviz.c
> @@ -0,0 +1,235 @@
> +/*
> + * copyright (c) 2010 S.N. Hemanth Meenakshisundaram 

> + * based on code in libavcodec/aviz.c by Fabrice Bellard

libavcodec/aviz.c, uh? There has ever been such a thing in libavcodec?

> + * and libavcodec/audioconvert.c by Michael Neidermayer
> + *
> + * 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
> + */
> +
> +/**
> + * @file
> + * aviz audio filter
> + */
> +
> +#include "avfilter.h"
> +#include "libavcodec/audioconvert.h"
> +
> +typedef struct {
> +short *sample_array;///< array of recent audio samples to be 
> used for visualization
> +int sample_array_index; ///< index of data being used
> +RDFTContext *rdft;  ///< DFT context for converting data into 
> frequency domain
> +int rdft_bits;  ///< DFT bits
> +FFTSample *rdft_data;   ///< frequency domain data
> +int nb_channels;///< number of channels of audio data
> +int screen_width;   ///< width of screen
> +int screen_height;  ///< height of screen
> +int hsub, vsub; ///< chroma subsampling values of required 
> output frames
> +int viz_type;   ///< visualize frequency or time domain data
> +AVFilterBufferRef *viz; ///< buffer that stores the visualized 
> picture data
> +} AVizContext;
> +
> +/* callback to get delay value from app and update other properties */
> +int (*app_callback) (int *delay; int *screen_w, int *screen_h, int 
> *viz_type);
> +
> +#define SAMPLE_ARRAY_SIZE (2*65536)
> +
> +static av_cold int init(AVFilterContext *ctx, const char *args, void *opaque)
> +{
> +AVizContext *aviz = ctx->priv;
> +int rdft_bits = 0, nb_freq = 0;
> +
> +aviz->sample_array = av_malloc(SAMPLE_ARRAY_SIZE * sizeof(short));
> +if (args){
> +sscanf(args, "%d:%d:%d", &aviz->screen_width, &aviz->screen_height, 
> &aviz->viz_type);
> +}
> +
> +for(rdft_bits=1; (1 +;
> +nb_freq= 1<<(rdft_bits-1);
> +
> +aviz->rdft = av_rdft_init(rdft_bits, DFT_R2C);
> +aviz->rdft_bits = rdft_bits;
> +aviz->rdft_data = av_malloc(4*nb_freq*sizeof(*s->rdft_data));
> +
> +/* TODO: Add error checking and configure callback function if there is 
> going to be one */
> +
> +return 0;
> +}
> +
> +static av_cold void uninit(AVFilterContext *ctx)
> +{
> +AVizContext *aviz = ctx->priv;
> +av_free(aviz->sample_array);
> +av_rdft_end(aviz->rdft);
> +av_free(aviz->rdft_data);
> +if (aviz->viz)
> +avfilter_unref_buffer(aviz->viz);
> +}
> +
> +static int input_config_props(AVFilterLink *link)
> +{
> +AVFilterContext *ctx = link->dst;
> +AVizContext *aviz = ctx->priv;
> +
> +aviz->nb_channels = 
> avcodec_channel_layout_num_channels(link->channel_layout);
> +
> +/

Re: [FFmpeg-soc] [PATCH] Move format from AVFilterBuffer to AVFilterPicRef

[Stefano Sabatini]

On date Wednesday 2010-08-04 14:10:13 +0200, Michael Niedermayer encoded:
> On Sun, Aug 01, 2010 at 11:41:09PM -0700, S.N. Hemanth Meenakshisundaram 
> wrote:
> >  ffplay.c  |8 
> >  libavfilter/avfilter.h|2 +-
> >  libavfilter/defaults.c|8 
> >  libavfilter/vf_overlay.c  |   12 ++--
> >  libavfilter/vsrc_buffer.c |2 +-
> >  libavfilter/vsrc_movie.c  |2 +-
> >  6 files changed, 17 insertions(+), 17 deletions(-)
> > 415376236550b0dd86fe180594d1f65f9d9d077f  
> > 0001-Move-format-from-AVFilterBuffer-to-AVFilterPicRef.patch
> 
> looks ok if tested

This is causing regressions here.

Hemanth, can you check it?

___
FFmpeg-soc mailing list
FFmpeg-soc@mplayerhq.hu
https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc

Re: [FFmpeg-soc] [PATCH] lavfi audio framework

[Stefano Sabatini]

On date Monday 2010-08-02 12:24:36 +0200, Stefano Sabatini encoded:
> On date Monday 2010-08-02 01:57:57 -0700, S.N. Hemanth Meenakshisundaram 
> encoded:
> > lavfi audio fw using the generalized AVFilterBufferRef struct. Anonymous
> > unions weren't allowed so I had to give the unions some names. Please
> > review and comment.

BTW post the reply to this on ffmpeg-devel, as it will affect the main
repo, so it should be discussed there.

Regards.
___
FFmpeg-soc mailing list
FFmpeg-soc@mplayerhq.hu
https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc

Re: [FFmpeg-soc] [PATCH] lavfi audio framework

[Stefano Sabatini]

On date Monday 2010-08-02 01:57:57 -0700, S.N. Hemanth Meenakshisundaram 
encoded:
> lavfi audio fw using the generalized AVFilterBufferRef struct. Anonymous
> unions weren't allowed so I had to give the unions some names. Please
> review and comment.
> 
> ---
>  ffmpeg.c |6 +-
>  ffplay.c |   12 ++--
>  libavfilter/avfilter.c   |   59 +-
>  libavfilter/avfilter.h   |  115 
> +++---
>  libavfilter/defaults.c   |  105 --
>  libavfilter/formats.c|3 +-
>  libavfilter/vf_aspect.c  |2 +-
>  libavfilter/vf_crop.c|4 +-
>  libavfilter/vf_drawbox.c |6 +-
>  libavfilter/vf_fifo.c|2 +-
>  libavfilter/vf_fps.c |2 +-
>  libavfilter/vf_hflip.c   |2 +-
>  libavfilter/vf_overlay.c |8 ++--
>  libavfilter/vf_pad.c |2 +-
>  libavfilter/vf_pixdesctest.c |2 +-
>  libavfilter/vf_rotate.c  |   12 ++--
>  libavfilter/vf_scale.c   |6 +-
>  libavfilter/vf_transpose.c   |   18 +++---
>  libavfilter/vsrc_buffer.c|8 ++--
>  19 files changed, 302 insertions(+), 72 deletions(-)

[...]
> diff --git a/libavfilter/avfilter.h b/libavfilter/avfilter.h
> index 96fca21..c433c6c 100644
> --- a/libavfilter/avfilter.h
> +++ b/libavfilter/avfilter.h
> @@ -99,21 +99,38 @@ typedef struct AVFilterBuffer
>  typedef struct AVFilterBufferRef
>  {
>  AVFilterBuffer *buf;///< the buffer that this is a reference to
> -uint8_t *data[4];   ///< picture data for each plane
> -int linesize[4];///< number of bytes per line
> -int w;  ///< image width
> -int h;  ///< image height
> +uint8_t *data[8];   ///< picture/audio data for each 
> plane/channel
> +int linesize[8];///< number of bytes per line
>  int format; ///< media format
> +int perms;  ///< permissions, see the AV_PERM_* flags
>  
>  int64_t pts;///< presentation timestamp in units of 
> 1/AV_TIME_BASE
>  int64_t pos;///< byte position in stream, -1 if unknown
>  
> -AVRational pixel_aspect;///< pixel aspect ratio
> -
> -int perms;  ///< permissions, see the AV_PERM_* flags
> +union {
> +AVRational pixel_aspect; ///< pixel aspect ratio of video buffer
> +int64_t channel_layout;  ///< channel layout of audio buffer
> +} desc;
> +
> +union {
> +int w;   ///< image width
> +int samples_nb;  ///< number of audio samples
> +} dim1;
> +union {
> +int h;   ///< image height
> +int size;///< audio buffer size
> +} dim2;
> +
> +union {
> +int interlaced;  ///< is video frame interlaced
> +uint32_t sample_rate;///< audio buffer sample rate
> +} prop;
> +
> +union {
> +int top_field_first; ///< video field order
> +int planar;  ///< audio buffer - planar or packed
> +} packing;
>  
> -int interlaced; ///< is frame interlaced
> -int top_field_first;
>  } AVFilterBufferRef;

My idea was:

typedef struct AVFilterBufferRefAudioProps {
enum SampleFormat format;
int size;
int samples_nb;  ///< number of audio samples
int planar;  ///< audio buffer - planar or packed
int64_t channel_layout;  ///< channel layout of audio buffer
} AVFilterBufferRefAudioProps;

typedef struct AVFilterBufferRefVideoProps {
enum PixelFormat format;
AVRational pixel_aspect; ///< pixel aspect ratio of video buffer
int w, h;
int interlaced;  ///< is video frame interlaced
int top_field_first; ///< video field order
} AVFilterBufferRefVideoProps;

typedef struct AVFilterBufferRef {
AVFilterBuffer *buf;///< the buffer that this is a reference to
uint8_t *data[8];   ///< picture/audio data for each plane/channel
int linesize[8];///< number of bytes per line
enum AVMediaType type;   

int format; ///< media format, this can be eventually moved 
to the media props
int perms;  ///< permissions, see the AV_PERM_* flags
  
int64_t pts;///< presentation timestamp in units of 
1/AV_TIME_BASE
int64_t pos;///< byte position in stream, -1 if unknown

union {
AVFilterBufferRefAudioProps audio;
AVFilterBufferRefVideoProps video;
} props;
} AVFilterBufferRef;

wxhere the semantics is:
"A filter buffer has a reference which has a media type and contains
some properties, which depends on the media type of the reference."

alternatively you may allocate the media props and reference them from
the AVFilterBufferRef through a void pointer:

void *pro

Re: [FFmpeg-soc] [PATCH] Rename pic fields in AVFilterLink to buf

[Stefano Sabatini]

On date Monday 2010-08-02 00:58:54 -0700, S.N. Hemanth Meenakshisundaram 
encoded:
> ---
> 
>  ffmpeg.c |4 ++--
>  ffplay.c |4 ++--
>  libavfilter/avfilter.c   |   34 +-
>  libavfilter/avfilter.h   |6 +++---
>  libavfilter/defaults.c   |   16 
>  libavfilter/vf_drawbox.c |2 +-
>  libavfilter/vf_drawtext.c|2 +-
>  libavfilter/vf_fade.c|6 +++---
>  libavfilter/vf_hflip.c   |4 ++--
>  libavfilter/vf_negate.c  |4 ++--
>  libavfilter/vf_pad.c |8 
>  libavfilter/vf_pixdesctest.c |8 
>  libavfilter/vf_rotate.c  |   18 +-
>  libavfilter/vf_scale.c   |8 
>  libavfilter/vf_split.c   |2 +-
>  libavfilter/vf_transpose.c   |   18 +-
>  libavfilter/vf_unsharp.c |4 ++--
>  17 files changed, 74 insertions(+), 74 deletions(-)

Looks fine.

As for the other patches, we have to wait for Michael explicit
approval, then I'll commit the patches to FFmpeg SVN.

Regards.
___
FFmpeg-soc mailing list
FFmpeg-soc@mplayerhq.hu
https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc

Re: [FFmpeg-soc] [PATCH] Rename avfilter_(un)ref_pic -> avfilter_(un)ref->buffer, AVFilterBufferRef pic->buffer

[Stefano Sabatini]

On date Sunday 2010-08-01 23:43:16 -0700, S.N. Hemanth Meenakshisundaram 
encoded:
> 
> avfilter_ref_pic, avfilter_unref_pic, avfilter_copy_picref_props all
> renamed to allow sharing with audio. AVFilterBuffer pointer of
> AVFilterBufferRef now named buf instead of pic.
> 
> ---
>  ffmpeg.c |2 +-
>  ffplay.c |   10 +-
>  libavfilter/avfilter.c   |   14 +++---
>  libavfilter/avfilter.h   |   34 +-
>  libavfilter/defaults.c   |   10 +-
>  libavfilter/vf_crop.c|2 +-
>  libavfilter/vf_fade.c|4 ++--
>  libavfilter/vf_fifo.c|2 +-
>  libavfilter/vf_fps.c |8 
>  libavfilter/vf_overlay.c |8 
>  libavfilter/vf_pad.c |8 
>  libavfilter/vf_pixdesctest.c |4 ++--
>  libavfilter/vf_rotate.c  |6 +++---
>  libavfilter/vf_scale.c   |4 ++--
>  libavfilter/vf_setpts.c  |2 +-
>  libavfilter/vf_split.c   |6 +++---
>  libavfilter/vf_transpose.c   |6 +++---
>  libavfilter/vf_unsharp.c |4 ++--
>  libavfilter/vsrc_buffer.c|4 ++--
>  libavfilter/vsrc_movie.c |4 ++--
>  20 files changed, 71 insertions(+), 71 deletions(-)

[...]

Looks OK.
___
FFmpeg-soc mailing list
FFmpeg-soc@mplayerhq.hu
https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc

Re: [FFmpeg-soc] [PATCH] Rename AVFilterPicRef->AVFilterBufferRef

[Stefano Sabatini]

On date Sunday 2010-08-01 23:41:57 -0700, S.N. Hemanth Meenakshisundaram 
encoded:
> This is to allow AVFilterBufferRef to be used for both audio and video.
> 
> ---
>  doc/APIchanges   |6 ++
>  ffmpeg.c |6 +++---
>  ffplay.c |   10 +-
>  libavfilter/avfilter.c   |   16 
>  libavfilter/avfilter.h   |   34 +-
>  libavfilter/defaults.c   |   10 +-
>  libavfilter/internal.h   |2 +-
>  libavfilter/vf_aspect.c  |2 +-
>  libavfilter/vf_crop.c|4 ++--
>  libavfilter/vf_drawbox.c |4 ++--
>  libavfilter/vf_drawtext.c|8 
>  libavfilter/vf_fade.c|   10 +-
>  libavfilter/vf_fifo.c|4 ++--
>  libavfilter/vf_fps.c |4 ++--
>  libavfilter/vf_hflip.c   |4 ++--
>  libavfilter/vf_negate.c  |4 ++--
>  libavfilter/vf_overlay.c |   18 +-
>  libavfilter/vf_pad.c |   14 +++---
>  libavfilter/vf_pixdesctest.c |8 
>  libavfilter/vf_rotate.c  |6 +++---
>  libavfilter/vf_scale.c   |6 +++---
>  libavfilter/vf_setpts.c  |6 +++---
>  libavfilter/vf_slicify.c |2 +-
>  libavfilter/vf_split.c   |2 +-
>  libavfilter/vf_transpose.c   |8 
>  libavfilter/vf_unsharp.c |4 ++--
>  libavfilter/vf_vflip.c   |6 +++---
>  libavfilter/vsink_nullsink.c |2 +-
>  libavfilter/vsrc_buffer.c|2 +-
>  libavfilter/vsrc_movie.c |4 ++--
>  30 files changed, 111 insertions(+), 105 deletions(-)
> 
> 
> 

> diff --git a/doc/APIchanges b/doc/APIchanges
> index b9de6d1..5dba97f 100644
> --- a/doc/APIchanges
> +++ b/doc/APIchanges
> @@ -13,6 +13,12 @@ libavutil:   2009-03-08
>  
>  API changes, most recent first:
>  
> +2010-08-01 - r24519 - lavfi 1.27.1 - rename AVFilterPicRef
> +  Rename AVFilterPicRef->AVFilterBufferRef
> +
> +2010-08-01 - r24519 - lavfi 1.27.0 - move format field
> +  Move the format field to AVFilterPicRef from AVFilterBuffer
> +
>  2010-07-27 - r24518 - lavcore 0.1.0 - parseutils.h
>Deprecate av_parse_video_frame_size() and av_parse_video_frame_rate()
>defined in libavcodec in favor of the newly added functions
> diff --git a/ffmpeg.c b/ffmpeg.c
> index 6f70516..67dcb9a 100644
> --- a/ffmpeg.c
> +++ b/ffmpeg.c
> @@ -313,7 +313,7 @@ typedef struct AVInputStream {
>  AVFilterContext *input_video_filter;
>  AVFrame *filter_frame;
>  int has_filter_frame;
> -AVFilterPicRef *picref;
> +AVFilterBufferRef *picref;
>  #endif
>  } AVInputStream;
>  
> @@ -361,10 +361,10 @@ static int output_query_formats(AVFilterContext *ctx)
>  }
>  
>  static int get_filtered_video_pic(AVFilterContext *ctx,
> -  AVFilterPicRef **picref, AVFrame *pic2,
> +  AVFilterBufferRef **picref, AVFrame *pic2,
>uint64_t *pts)
>  {
> -AVFilterPicRef *pic;
> +AVFilterBufferRef *pic;
>  
>  if(avfilter_request_frame(ctx->inputs[0]))
>  return -1;
> diff --git a/ffplay.c b/ffplay.c
> index c976f09..9b523de 100644
> --- a/ffplay.c
> +++ b/ffplay.c
> @@ -105,7 +105,7 @@ typedef struct VideoPicture {
>  enum PixelFormat pix_fmt;
>  
>  #if CONFIG_AVFILTER
> -AVFilterPicRef *picref;
> +AVFilterBufferRef *picref;
>  #endif
>  } VideoPicture;
>  
> @@ -1560,7 +1560,7 @@ typedef struct {
>  static int input_get_buffer(AVCodecContext *codec, AVFrame *pic)
>  {
>  AVFilterContext *ctx = codec->opaque;
> -AVFilterPicRef  *ref;
> +AVFilterBufferRef  *ref;
>  int perms = AV_PERM_WRITE;
>  int i, w, h, stride[4];
>  unsigned edge;
> @@ -1609,7 +1609,7 @@ static void input_release_buffer(AVCodecContext *codec, 
> AVFrame *pic)
>  
>  static int input_reget_buffer(AVCodecContext *codec, AVFrame *pic)
>  {
> -AVFilterPicRef *ref = pic->opaque;
> +AVFilterBufferRef *ref = pic->opaque;
>  
>  if (pic->data[0] == NULL) {
>  pic->buffer_hints |= FF_BUFFER_HINTS_READABLE;
> @@ -1656,7 +1656,7 @@ static void input_uninit(AVFilterContext *ctx)
>  static int input_request_frame(AVFilterLink *link)
>  {
>  FilterPriv *priv = link->src->priv;
> -AVFilterPicRef *picref;
> +AVFilterBufferRef *picref;
>  int64_t pts = 0;
>  AVPacket pkt;
>  int ret;
> @@ -1741,7 +1741,7 @@ static int output_query_formats(AVFilterContext *ctx)
>  static int get_filtered_video_frame(AVFilterContext *ctx, AVFrame *frame,
>  int64_t *pts, int64_t *pos)
>  {
> -AVFilterPicRef *pic;
> +AVFilterBufferRef *pic;
>  
>  if(avfilter_request_frame(ctx->inputs[0]))
>  return -1;
> diff --git a/libavfilter/avfilter.c b/libavfilter/avfilter.c
> index c040a9c..c2061e2 100644
> --- a/libavfilter/avfilter.c
> +++ b/libavfilter/avfilter.c
> @@ -45,16 +45,16 @@ const char *avfilter_license(void)

Re: [FFmpeg-soc] [PATCH] Move format from AVFilterBuffer to AVFilterPicRef

[Stefano Sabatini]

On date Sunday 2010-08-01 23:41:09 -0700, S.N. Hemanth Meenakshisundaram 
encoded:
> 
> ---
>  ffplay.c  |8 
>  libavfilter/avfilter.h|2 +-
>  libavfilter/defaults.c|8 
>  libavfilter/vf_overlay.c  |   12 ++--
>  libavfilter/vsrc_buffer.c |2 +-
>  libavfilter/vsrc_movie.c  |2 +-
>  6 files changed, 17 insertions(+), 17 deletions(-)
> 
> 
> 

> diff --git a/ffplay.c b/ffplay.c
> index c200119..c976f09 100644
> --- a/ffplay.c
> +++ b/ffplay.c
> @@ -1585,8 +1585,8 @@ static int input_get_buffer(AVCodecContext *codec, 
> AVFrame *pic)
>  ref->w = codec->width;
>  ref->h = codec->height;
>  for(i = 0; i < 4; i ++) {
> -unsigned hshift = (i == 1 || i == 2) ? 
> av_pix_fmt_descriptors[ref->pic->format].log2_chroma_w : 0;
> -unsigned vshift = (i == 1 || i == 2) ? 
> av_pix_fmt_descriptors[ref->pic->format].log2_chroma_h : 0;
> +unsigned hshift = (i == 1 || i == 2) ? 
> av_pix_fmt_descriptors[ref->format].log2_chroma_w : 0;
> +unsigned vshift = (i == 1 || i == 2) ? 
> av_pix_fmt_descriptors[ref->format].log2_chroma_h : 0;
>  
>  if (ref->data[i]) {
>  ref->data[i]+= (edge >> hshift) + ((edge * ref->linesize[i]) 
> >> vshift);
> @@ -1617,7 +1617,7 @@ static int input_reget_buffer(AVCodecContext *codec, 
> AVFrame *pic)
>  }
>  
>  if ((codec->width != ref->w) || (codec->height != ref->h) ||
> -(codec->pix_fmt != ref->pic->format)) {
> +(codec->pix_fmt != ref->format)) {
>  av_log(codec, AV_LOG_ERROR, "Picture properties changed.\n");
>  return -1;
>  }
> @@ -1671,7 +1671,7 @@ static int input_request_frame(AVFilterLink *link)
>  } else {
>  picref = avfilter_get_video_buffer(link, AV_PERM_WRITE, link->w, 
> link->h);
>  av_picture_copy((AVPicture *)&picref->data, (AVPicture *)priv->frame,
> -picref->pic->format, link->w, link->h);
> +picref->format, link->w, link->h);
>  }
>  av_free_packet(&pkt);
>  
> diff --git a/libavfilter/avfilter.h b/libavfilter/avfilter.h
> index 45340b2..6625052 100644
> --- a/libavfilter/avfilter.h
> +++ b/libavfilter/avfilter.h
> @@ -68,7 +68,6 @@ typedef struct AVFilterBuffer
>  {
>  uint8_t *data[8];   ///< buffer data for each plane
>  int linesize[8];///< number of bytes per line
> -int format; ///< media format
>  
>  unsigned refcount;  ///< number of references to this buffer
>  
> @@ -104,6 +103,7 @@ typedef struct AVFilterPicRef
>  int linesize[4];///< number of bytes per line
>  int w;  ///< image width
>  int h;  ///< image height
> +int format; ///< media format
>  
>  int64_t pts;///< presentation timestamp in units of 
> 1/AV_TIME_BASE
>  int64_t pos;///< byte position in stream, -1 if unknown
> diff --git a/libavfilter/defaults.c b/libavfilter/defaults.c
> index 8deef93..ab7be77 100644
> --- a/libavfilter/defaults.c
> +++ b/libavfilter/defaults.c
> @@ -47,17 +47,17 @@ AVFilterPicRef 
> *avfilter_default_get_video_buffer(AVFilterLink *link, int perms,
>  ref->perms = perms | AV_PERM_READ;
>  
>  pic->refcount = 1;
> -pic->format   = link->format;
> +ref->format   = link->format;
>  pic->free = avfilter_default_free_buffer;
> -av_fill_image_linesizes(pic->linesize, pic->format, ref->w);
> +av_fill_image_linesizes(pic->linesize, ref->format, ref->w);
>  
>  for (i=0; i<4;i++)
>  pic->linesize[i] = FFALIGN(pic->linesize[i], 16);
>  
> -tempsize = av_fill_image_pointers(pic->data, pic->format, ref->h, NULL, 
> pic->linesize);
> +tempsize = av_fill_image_pointers(pic->data, ref->format, ref->h, NULL, 
> pic->linesize);
>  buf = av_malloc(tempsize + 16); // +2 is needed for swscaler, +16 to be
>  // SIMD-friendly
> -av_fill_image_pointers(pic->data, pic->format, ref->h, buf, 
> pic->linesize);
> +av_fill_image_pointers(pic->data, ref->format, ref->h, buf, 
> pic->linesize);
>  
>  memcpy(ref->data, pic->data, sizeof(pic->data));
>  memcpy(ref->linesize, pic->linesize, sizeof(pic->linesize));
> diff --git a/libavfilter/vf_overlay.c b/libavfilter/vf_overlay.c
> index 26b9d4f..defc5b8 100644
> --- a/libavfilter/vf_overlay.c
> +++ b/libavfilter/vf_overlay.c
> @@ -210,7 +210,7 @@ static void copy_image_rgb(AVFilterPicRef *dst, int x, 
> int y,
>  pic.data[0] += x * bpp;
>  pic.data[0] += y * pic.linesize[0];
>  
> -if (src->pic->format == PIX_FMT_BGRA) {
> +if (src->format == PIX_FMT_BGRA) {
>  for (y = 0; y < h; y++) {
>uint8_t *optr = pic.data[0]  + y * pic.linesize[0];
>  const uint8_t *iptr = src->data[0] + y * src->linesize[0];
> @@ -224,7 +224,7 @@ static void copy_image_rgb(AVFi

Re: [FFmpeg-soc] [PATCH] fixes for asrc_buffer

[Stefano Sabatini]

On date Saturday 2010-07-31 09:49:02 -0700, S.N. Hemanth Meenakshisundaram 
encoded:
> On 07/31/2010 07:08 AM, Stefano Sabatini wrote:
> > On date Saturday 2010-07-31 03:27:14 -0700, S.N. Hemanth Meenakshisundaram 
> > encoded:
> >   
> >> Some fixes to the asrc_buffer. Add config props since src filter has no
> >> inputs and default config props will fail.
> >>
> >> ---
> >>  libavfilter/allfilters.c  |2 +-
> >>  libavfilter/asrc_buffer.c |   10 --
> >>  2 files changed, 9 insertions(+), 3 deletions(-)
> >>
> >>
> >>
> >> 
> >   
> >> diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c
> >> index 6a828fa..069c56c 100644
> >> --- a/libavfilter/allfilters.c
> >> +++ b/libavfilter/allfilters.c
> >> @@ -60,7 +60,7 @@ void avfilter_register_all(void)
> >>  REGISTER_FILTER (UNSHARP, unsharp, vf);
> >>  REGISTER_FILTER (VFLIP,   vflip,   vf);
> >>  
> >> -REGISTER_FILTER (ABUFFER, abuffer, asrc);
> >> +REGISTER_FILTER (ABUFFER, buffer,  asrc);
> >> 
> > I suppose this hunk is wrong.
> >   
> 
> This works because the file is currently named asrc_buffer.c while the
> string name of the filter is abuffer to avoid clashes with vsrc_buffer
> (which is called "buffer"). I guess this is inconsistent. I will rename
> asrc_buffer.* to asrc_abuffer if that's acceptable.

Ah OK, yes renaming the file would be good.

Regards.
___
FFmpeg-soc mailing list
FFmpeg-soc@mplayerhq.hu
https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc

Re: [FFmpeg-soc] Fwd: [PATCH] ffmpeg.c changes for calling lavfi audio framework

[Stefano Sabatini]

On date Saturday 2010-07-31 03:35:35 -0700, S.N. Hemanth Meenakshisundaram 
encoded:
> ffmpeg changes to call lavfi audio framework. It works but is a
> temporary way to test the other audio filters. Couple if issues with this:
> 
> 1. Right now, asrc and ffmpeg.c copy any incoming audio frames and thewn
> copy them back out. To avoid the two memcpy calls. is it ok to implement
> interfaces to avoid this? Please let me know.

To avoid useless memcpy is a requirement for main SVN integration. 

> I was thinking of defining alternative get_video_buffer and
> unref_samples to pass in a buffer pointer alone and use this as input
> parameter. Comments?

Elaborate more on this.

[...]

Regards.
___
FFmpeg-soc mailing list
FFmpeg-soc@mplayerhq.hu
https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc

Re: [FFmpeg-soc] [PATCH] fixes for asrc_buffer

[Stefano Sabatini]

On date Saturday 2010-07-31 03:27:14 -0700, S.N. Hemanth Meenakshisundaram 
encoded:
> 
> Some fixes to the asrc_buffer. Add config props since src filter has no
> inputs and default config props will fail.
> 
> ---
>  libavfilter/allfilters.c  |2 +-
>  libavfilter/asrc_buffer.c |   10 --
>  2 files changed, 9 insertions(+), 3 deletions(-)
> 
> 
> 

> diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c
> index 6a828fa..069c56c 100644
> --- a/libavfilter/allfilters.c
> +++ b/libavfilter/allfilters.c
> @@ -60,7 +60,7 @@ void avfilter_register_all(void)
>  REGISTER_FILTER (UNSHARP, unsharp, vf);
>  REGISTER_FILTER (VFLIP,   vflip,   vf);
>  
> -REGISTER_FILTER (ABUFFER, abuffer, asrc);
> +REGISTER_FILTER (ABUFFER, buffer,  asrc);

I suppose this hunk is wrong.

[...]

Regards.
___
FFmpeg-soc mailing list
FFmpeg-soc@mplayerhq.hu
https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc

Re: [FFmpeg-soc] [PATCH] Add asrc_buffer filter

[Stefano Sabatini]

On date Wednesday 2010-07-28 00:29:38 -0700, S.N. Hemanth Meenakshisundaram 
encoded:
> Added an asrc buffer. Uses AVFifoBuffer like in Baptiste's vsrc patch.
> My ffmpeg.c changes aren't yet complete, will test with ffmpeg.c this
> once that is done.
> 
> ---
>  libavfilter/Makefile  |2 +
>  libavfilter/allfilters.c  |2 +
>  libavfilter/asrc_buffer.c |  128 
> +
>  libavfilter/asrc_buffer.h |   24 
>  4 files changed, 156 insertions(+), 0 deletions(-)
>  create mode 100644 libavfilter/asrc_buffer.c
>  create mode 100644 libavfilter/asrc_buffer.h

Looks OK, but:
* check the latest fixes to the vsrc_buffer, and apply them here
* add missing docs for both asrc_buffer.h and filter.texi

Regards.
___
FFmpeg-soc mailing list
FFmpeg-soc@mplayerhq.hu
https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc

Re: [FFmpeg-soc] [soc] libavsequencer [PATCH 01/08] Music module public API header file.

[Stefano Sabatini]

On date Saturday 2010-07-10 15:11:03 +0200, Sebastian Vater encoded:
> Sebastian Vater a écrit :
[...]
> Please update your repository pointing to
> http://github.com/BastyCDGS/ffmpeg-soc
> 
> One question though, should I mail such small patches here also, or is
> it enough to mention that they are fixed?

Yes please post the patches here, we are lazy-busy so having less
steps to do will help to make review faster, also posting the patch
allows in-line comments.

Regards.
___
FFmpeg-soc mailing list
FFmpeg-soc@mplayerhq.hu
https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc

Re: [FFmpeg-soc] [soc] libavsequencer [PATCH 01/08] Music module public API header file.

[Stefano Sabatini]

On date Wednesday 2010-07-07 22:46:08 +0200, Sebastian Vater encoded:
> 
> -- 
> 
> Best regards,
>:-) Basty/CDGS (-:
> 

> diff --git a/libavsequencer/module.h b/libavsequencer/module.h
> new file mode 100755
> index 000..af8fa89
> --- /dev/null
> +++ b/libavsequencer/module.h
> @@ -0,0 +1,124 @@
> +/*
> + * AVSequencer music module management
> + * Copyright (c) 2010 Sebastian Vater 
> + *
> + * 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 AVSEQUENCER_MODULE_H
> +#define AVSEQUENCER_MODULE_H
> +
> +#include "libavsequencer/avsequencer.h"
> +#include "libavsequencer/player.h"
> +#include "libavutil/tree.h"
> +
> +/**
> + * Sequencer module structure.
> + * New fields can be added to the end with minor version bumps.
> + * Removal, reordering and changes to existing fields require a major
> + * version bump.
> + */

Please describe the general architecture for libavsequencer.  It looks
really complex, and we need to understand how the various components
iteract. In particular we need to understand how a mod decoder can be
built and integrated into FFmpeg.

In particular we need to understand which will be the role of the
player, which will likely be the first component to be reviewed.

> +typedef struct AVSequencerModule {
> +/** Metadata information: Original module file name, module name,
> + *  module message, artist, genre, album, begin and finish date of
> + * composition and comment.  */
> +AVSequencerMetadata *metadata;

AVSequencerMetadata is not shown in your patches, also I wonder, won't
be this a repetition of libavformat AVMetaData?

> +
> +/** AVSequencerPlayerChannel pointer to virtual channel data.  */
> +AVSequencerPlayerChannel *channel_data;

Same I cannot see definition for this.

> +
> +/** Integer indexed tree root of sub-songs available in
> +   this module with AVTreeNode->elem being a AVSequencerSong.  */
> +AVTreeNode *song_list;
> +
> +/** Integer indexed tree root of instruments available for
> +   the whole module (shared between all sub-songs) with
> +   AVTreeNode->elem being a AVSequencerInstrument.  */
> +AVTreeNode *instrument_list;
> +
> +/** Integer indexed tree root of envelopes used by module
> +   with AVTreeNode->elem being a AVSequencerEnvelope.
> +   There can be vibrato, tremolo, panbrello, spenolo,
> +   volume, panning, pitch, envelopes, a resonance filter and
> +   finally the auto vibrato, tremolo and panbrello envelopes.  */
> +AVTreeNode *envelopes_list;
> +
> +/** Integer indexed tree root of keyboard definitions
> +   with AVTreeNode->elem being a AVSequencerKeyboard.
> +   A keyboard definition maps an instrument octave/note-pair
> +   to the sample number being played.  */
> +AVTreeNode *keyboard_list;
> +
> +/** Integer indexed tree root of arpeggio envelopes
> +   with AVTreeNode->elem being a AVSequencerArpeggioEnvelope.
> +   Arpeggio envelopes allow to fully customize the arpeggio
> +   command by playing the envelope instead of only a 
> +   repetive set of 3 different notes.  */
> +AVTreeNode *arp_env_list;
> +
> +/** Duration of the module, in AV_TIME_BASE fractional
> +   seconds. This is the total sum of all sub-song durations
> +   this module contains.  */
> +uint64_t duration;
> +
> +/** Maximum number of virtual channels, including NNA (New Note
> +   Action) background channels to be allocated and processed by
> +   the mixing engine (defaults to 64).  */
> +uint16_t channels;
> +#define AVSEQ_MODULE_CHANNELS   64
> +
> +/** Compatibility flags for playback. There are rare cases
> +   where effect handling can not be mapped into internal
> +   playback engine and have to be handled specially. For
> +   each module which needs this, this will define new
> +   flags which tag the player to handle it to that special
> +   way.  */
> +int8_t compat_flags;
> +
> +/** Module playback flags.  */
> +int8_t flags;
> +
> +/** 64-bit integer indexed unique key tree root of unknown data
> +   fields for input file reading with AVTreeNode->elem being
> +   unsigned 8-bit in

Re: [FFmpeg-soc] [soc] Questions on patch order, threads and review comments

[Stefano Sabatini]

On date Tuesday 2010-07-06 02:45:09 -0700, S.N. Hemanth Meenakshisundaram 
encoded:
> 
> Hi Stefano,
> 
> I have a few questions on the order of patches and on some of your review
> comments from earlier:
> 
> >> >
> >> >Here is the working af_resample.c and associated Makefile and
> >> >allfilters.c changes.
> >> >
> >> >[...]
> >>
> >>
> >
> >> -#define AV_PERM_READ 0x01   ///< can read from the buffer
> >> -#define AV_PERM_WRITE0x02   ///< can write to the buffer
> >> -#define AV_PERM_PRESERVE 0x04   ///< nobody else can overwrite the
> >> buffer
> >> -#define AV_PERM_REUSE0x08   ///< can output the buffer multiple
> >> times, with the same contents each time
> >> -#define AV_PERM_REUSE2   0x10   ///< can output the buffer multiple
> >> times, modified each time
> >
> > The AV_PERM_* moving can go to a separate patch.
> 
> Should I submit the AV_PERM_* patch first (move it out of AVFilterPicRef
> structure) and then the the audio framework changes patch? Or should I
> focus on the audio filter patches and define the PERM macros twice (inside
> AVFilterPicRef and AVFilterSamplesRef structures).

Possibly to a separate change chronologically done *before* the audio
framework patch. The objective is to make the audio framework patch
smaller and simplify review. Also the first one should be pretty easy
and pretty fast to get applied.

Note that with git that shouldn't be at all an issue, you can work out
the patches in a branch, change their position, merge and split them
using git rebase -i, and no-one is preventing you to send many patches
in a branch, so they can start to be discussed even when the
pre-requisite patches (like this one) have not yet been applied.

> >
> >> -link->format = link->in_formats->formats[0];
> >> +if (link->type == AVMEDIA_TYPE_VIDEO)
> >> +link->format = link->in_formats->formats[0];
> >> +else if (link->type == AVMEDIA_TYPE_AUDIO)
> >> +link->aformat = link->in_formats->aformats[0];
> >
> > simpler: link->format = type == VIDEO ? link->in_formats->formats[0] :
> > link->in_formats->aformats[0];
> 
> Here I need to assign to link->format in case of video and link->aformat
> in case of audio. How can I get this done using the ?: form above?

Forget about that, my suggestion was just wrong.
And you can put them in a single line to help readability if you
prefer it:

if  (link->type == AVMEDIA_TYPE_VIDEO) link->format  = 
link->in_formats->formats[0];
else if (link->type == AVMEDIA_TYPE_AUDIO) link->aformat = 
link->in_formats->aformats[0];

> >
> >> +#define CMP_AND_ADD(acount, bcount, afmt, bfmt, retfmt) { \
> >> +for(i = 0; i < acount; i++) \
> >> +for(j = 0; j < bcount; j++) \
> >> +if(afmt[i] == bfmt[j]) \
> >> +retfmt[k++] = afmt[i]; \
> >> +}
> >> [...]
> >>
> >
> > This refactoring is nice but please split it in a separate patch (and
> > separate thread).
> 
> Again, should I submit the CMP_AND_ADD refactoring patch first before the
> audio filter patches?

You can send them *before* or *togheter* as you see fit.
 
> I should start a new thread for each patch - is that right?

Possibly, that help the reviewer/committer to understand if a
*specific* patch has been already approved / committed, better than
browse through all the mails in a super-long thread.
 
> Also, I now have some patches based on your comments and some of the
> additions for channel layout conversion etc.
> 
> Should I send these as patches of patches or send the entire patch each
> time starting from whatever is not yet in the soc svns? Patches of patches
> would be difficult to read while sending the entire patch again hides the
> new changes.

Patches as issued by git should be fine to post, and the number in the
patch help to clarify the dependencies of the patch.

> Finally, Wikipedia says the downmix formulae for ac3 to stereo are:
> 
> Left Only = Left (Front) + -3dB*Center + att*LeftSide
> 
> Right Only = Right (Front) + -3dB*Center + att*RightSide
> 
> where att = -3dB, -6dB or -9dB.
> 
> The article has no references. Can I just go ahead and use this? It seems
> to work well for a 5.0 track I have with att = -9dB.

If it works and some audio-competent reviewer approve it should be
safe, anyway a reference in the code to the original article would be
nice / useful.

Regards.
___
FFmpeg-soc mailing list
FFmpeg-soc@mplayerhq.hu
https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc

Re: [FFmpeg-soc] [soc]: r5841 - libavfilter/vf_overlay.c

[Stefano Sabatini]

On date Sunday 2010-06-20 16:31:19 -0700, Baptiste Coudurier encoded:
> On 6/20/10 4:27 PM, stefano wrote:
> >Author: stefano
> >Date: Mon Jun 21 01:27:14 2010
> >New Revision: 5841
> >
> >Log:
> >Revert commit:
> >   Author: bcoudurier
> >   Date: Fri Jun  4 22:15:35 2010
> >   New Revision: 5821
> >
> >   Log:
> >   Direct rendering in overlay filter.
> >   RGB24 support.
> >   Doesn't work with movie in movie yet, needs loop input feature for logos
> >   either in movie filter or here.
> >
> >Fix movie in movie and ffplay overlaying with static images, ffplay
> >movie in movie filtering is still borken.
> 
> This is false, ffplay works here with static images, _your_ setup is broken.

I could have expressed it better, what is not working is overlay with
a dynamic movie:
ffplay -vf "movie=0:flv:slow.flv, scale=100:-1 [overlay]; [in][overlay] 
overlay" slow.flv

A black rectangle is overlayed.
___
FFmpeg-soc mailing list
FFmpeg-soc@mplayerhq.hu
https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc

Re: [FFmpeg-soc] [soc]: r5821 - libavfilter/vf_overlay.c

[Stefano Sabatini]

On date Friday 2010-06-11 03:06:30 -0700, Baptiste Coudurier encoded:
> On 6/9/10 4:49 PM, Baptiste Coudurier wrote:
> >On 06/09/2010 03:22 PM, Stefano Sabatini wrote:
> >>On date Friday 2010-06-04 22:15:35 +0200, bcoudurier encoded:
> >>>Author: bcoudurier
> >>>Date: Fri Jun 4 22:15:35 2010
> >>>New Revision: 5821
> >>>
> >>>Log:
> >>>Direct rendering in overlay filter.
> >>>RGB24 support.
> >>>Doesn't work with movie in movie yet, needs loop input feature for logos
> >>>either in movie filter or here.
> >>
> >>This broke movie in movie.
> >
> >Yes, I mentioned this in the commit log :)
> >
> >>Again, please *don't* make massive changes and introduce regressions
> >>without not even posting and discussing the changes before, testing
> >>with ffplay is a bonus.
> >>
> >>Consider to fix the regression or revert the patch if you can't do it
> >>in a reasonable amount of time, or at least try to justify because
> >>this change should be an improvement over the previous behaviour.
> 
> Besides, I believe you are overreacting here. If you can't realize why
> direct rendering is way better that what was in before, I can't help you.

I have this rewrite of ffmpeg which makes it much faster:
int main(void) { return 0; }

increasing speed should not be done at expenses of functionality, I
prefer a slow filter which works in every scenarios rather than a fast
filter which only works in particular cases.

> And if you had reviewed the filter you would have seen that there is a
> commented test about pts which would fetch the next frame from the
> overlayed source.
> My comment about loop input is pretty clear, if you actually read
> the code...
> If you overlay a logo, you want the input to loop, if you are
> overlayed a video, you don't want the last frame to loop.
>
> Besides the previous code with pts was weird, the output pts should
> always be the main video pts AFAIU.
> 
> I'd appreciate if people could actually review the changes and make
> constructive comments.

My point is that we should try to not break working stuff, people is
already using this repo, breaking previously working stuff should be
avoided, that's true especially for the filter providing the most
required functionality, saying on the user ML "sorry but my last
commit broke overlay, I hope someone will fix it soon or later" is not
going to cast good karma on the project.

If your changes required the implementation of a loop mechanism you're
recommended to implement that *before* to apply those changes, I'm for
sure not going to fix this as I have already too many things queued on
my todo.

I'm all for improving the current code and I appreciate your work, but
I'd like to review changes *before* to see them committed, especially
if they break previously working features.

Regards.
___
FFmpeg-soc mailing list
FFmpeg-soc@mplayerhq.hu
https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc

Re: [FFmpeg-soc] [soc]: r5821 - libavfilter/vf_overlay.c

[Stefano Sabatini]

On date Friday 2010-06-04 22:15:35 +0200, bcoudurier encoded:
> Author: bcoudurier
> Date: Fri Jun  4 22:15:35 2010
> New Revision: 5821
> 
> Log:
> Direct rendering in overlay filter.
> RGB24 support.
> Doesn't work with movie in movie yet, needs loop input feature for logos
> either in movie filter or here.

This broke movie in movie.

Again, please *don't* make massive changes and introduce regressions
without not even posting and discussing the changes before, testing
with ffplay is a bonus.

Consider to fix the regression or revert the patch if you can't do it
in a reasonable amount of time, or at least try to justify because
this change should be an improvement over the previous behaviour.

> Modified:
>libavfilter/vf_overlay.c
> 
> Modified: libavfilter/vf_overlay.c
> ==
> --- libavfilter/vf_overlay.c  Fri Jun  4 22:10:23 2010(r5820)
> +++ libavfilter/vf_overlay.c  Fri Jun  4 22:15:35 2010(r5821)
> @@ -1,5 +1,6 @@
>  /*
>   * copyright (c) 2007 Bobby Bingham
> + * copyright (c) 2010 Baptiste Coudurier
>   *
>   * This file is part of FFmpeg.
>   *
> @@ -44,13 +45,9 @@ enum var_name {
>  };
>  
>  typedef struct {
> -int x, y;   //< position of subpicture
> +unsigned x, y;  //< position of subpicture
>  
> -/** pics[0][0..1] are pictures for the main image.
> - *  pics[1][0..1] are pictures for the sub image.
> - *  pics[x][0]are previously outputted images.
> - *  pics[x][1]are queued, yet unused frames for each input. */
> -AVFilterPicRef *pics[2][2];
> +AVFilterPicRef *overlay;
>  
>  int bpp;//< bytes per pixel

bpp (whose name and documentation was just wrong) is not used anymore.

Regards.
___
FFmpeg-soc mailing list
FFmpeg-soc@mplayerhq.hu
https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc

Re: [FFmpeg-soc] [RFC] rename vsrc movie to vsrc file

[Stefano Sabatini]

On date Wednesday 2010-06-09 03:00:05 -0700, Baptiste Coudurier encoded:
> On 5/11/10 3:39 PM, Baptiste Coudurier wrote:
> >On 05/11/2010 03:18 PM, Stefano Sabatini wrote:
> >>On date Wednesday 2010-05-12 00:10:28 +0200, Vitor Sessak encoded:
> >>>Víctor Paesa wrote:
> >>>>Hi
> >>>>
> >>>>On Tue, May 11, 2010 at 21:46, Vitor Sessak wrote:
> >>>>>Baptiste Coudurier wrote:
> >>>>>>Guys,
> >>>>>>
> >>>>>>What do you think about it ?
> >>>>>Looks a good idea to me, unless someone comes up with an even
> >>>>>better name.
> >>>>>
> >>>>
> >>>>Well, strictly speaking, not only files are supported.
> >>>
> >>>But for me "file" is still the least misleading. For example, in
> >>>"ffmpeg -h":
> >>>
> >>>>-i filename input file name
> >>>
> >>>We already call [file|URL|video4windows device number] a "file"...
> >>
> >>Exactly. What we're really taking in input is a lavf
> >>resource/source/stream.
> >>
> >>Maybe vsrc_stream, but I continue to prefer "lavf" as it is using the
> >>lavf syntax/capabilities.
> >>
> >
> >I think users don't really know about lavf, it won't be obvious for them
> >at all...
> >
> 
> So, victor, stefano ? Do we agree on a name or ? Michael what do you think ?

I'm for (in this order):

* vsrc_lavf (and explain in details where this name comes from, and
  its capabilities)

* vsrc_movie -> same as currently, yet better than vsrc_file which is
  misleading IMHO.
 
> Can you guys please review vsrc_movie.c ?

I'll try to do it this night, please start by posting the patch to
ffmpeg-devel.

> It would be nice to have overlay in svn.

+1.

Regards.
___
FFmpeg-soc mailing list
FFmpeg-soc@mplayerhq.hu
https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc

Re: [FFmpeg-soc] [soc]: r5821 - libavfilter/vf_overlay.c

[Stefano Sabatini]

On date Tuesday 2010-06-08 15:21:07 -0700, Baptiste Coudurier encoded:
> On 6/5/10 4:19 PM, Stefano Sabatini wrote:
> >On date Saturday 2010-06-05 15:33:21 -0700, Baptiste Coudurier encoded:
> >>On 6/5/10 2:33 PM, Stefano Sabatini wrote:
> >>>On date Saturday 2010-06-05 14:02:32 -0700, Baptiste Coudurier encoded:
> >>>>Hi Stefano,
> >>>>
> >>>>On 6/5/10 6:38 AM, Stefano Sabatini wrote:
> >>>>>On date Friday 2010-06-04 22:15:35 +0200, bcoudurier encoded:
> >>>>>>Author: bcoudurier
> >>>>>>Date: Fri Jun  4 22:15:35 2010
> >>>>>>New Revision: 5821
> >>>>>>
> >>>>>>Log:
> >>>>>>Direct rendering in overlay filter.
> >>>>>>RGB24 support.
> >>>>>>Doesn't work with movie in movie yet, needs loop input feature for logos
> >>>>>>either in movie filter or here.
> >>>>>
> >>>>>Overlay filter is now badly broken in a weird funny way.
> >>>>>
> >>>>>May I ask you to avoid to commit features which cause regressions?
> >>>>
> >>>>What's broken exactly ?
> >>>
> >>>ffplay -vf "movie=0:png:logo.png, scale=100:-1 [logo]; [in][logo] 
> >>>overlay=10:main_h-overlay_h-10:1 [out]" slow.flv
> >>>
> >>>and sorry for the rude reply, now I see that you test only with ffmpeg
> >>>and not with ffplay (also the fade filter has serious problems when
> >>>used with ffplay).
> >>
> >>That's ok, it seems you improperly translated to the new API.
> >
> >100l to me.
> >
> >>It works fine here now.
> >
> >Anyway the problem is another one, try with a MPEG video based codec
> >and you should see. What I'm observing is that the overlay is applied
> >to the source filter *before* the motion compensation, the
> >(weird|funny) result is that the logo tends to stain the image
> >sort-alike ink as the video scrolls.
> 
> Stefano, do you still have the issue ?
> I believe the overlay filter should be commited to svn.
> Michael, could you please review it ? Or do you want me to send it
> to ffmpeg-devel ?

Yes, the problem depends on the ffplay implementation (which doesn't
rely on av_vsrc_buffer), I still didn't looked at it, that for sure
should be addressed before to commit it to SVN.

Also please post the patch anyway, there are some points I want to
address in the review (mainly trivial stuff).

Regards.
___
FFmpeg-soc mailing list
FFmpeg-soc@mplayerhq.hu
https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc

Re: [FFmpeg-soc] Git Account Request

[Stefano Sabatini]

On date Sunday 2010-06-06 10:35:46 -0700, S.N. Hemanth Meenakshisundaram 
encoded: 
> >> On date Saturday 2010-06-05 13:24:35 -0700, S.N. Hemanth
> >> Meenakshisundaram
> >> encoded:
> >> [...]
> >> Hi All,
> >> Attached is a rough draft of the audio API. I am now writing a
> >> simple volume scaling filter using this API. Please review and
> >> comment. Some observations:
> >> [...]
> > BTW let us know if you want to work on a SOC SVN repo or with
> > github/gitorius/whatever, the last option should be the more flexible
> for you.
> 
> Hi Stefano,
> 
> Can I get a Git account so I can work on a branch. What should I do for this?

Follow the instructions given here:
http://wiki.multimedia.cx/index.php?title=Hosting_SoC_Repo_On_Github

Let me know if you have problems setting it up.

Regards.
___
FFmpeg-soc mailing list
FFmpeg-soc@mplayerhq.hu
https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc

Re: [FFmpeg-soc] [soc]: r5821 - libavfilter/vf_overlay.c

[Stefano Sabatini]

On date Saturday 2010-06-05 15:33:21 -0700, Baptiste Coudurier encoded:
> On 6/5/10 2:33 PM, Stefano Sabatini wrote:
> >On date Saturday 2010-06-05 14:02:32 -0700, Baptiste Coudurier encoded:
> >>Hi Stefano,
> >>
> >>On 6/5/10 6:38 AM, Stefano Sabatini wrote:
> >>>On date Friday 2010-06-04 22:15:35 +0200, bcoudurier encoded:
> >>>>Author: bcoudurier
> >>>>Date: Fri Jun  4 22:15:35 2010
> >>>>New Revision: 5821
> >>>>
> >>>>Log:
> >>>>Direct rendering in overlay filter.
> >>>>RGB24 support.
> >>>>Doesn't work with movie in movie yet, needs loop input feature for logos
> >>>>either in movie filter or here.
> >>>
> >>>Overlay filter is now badly broken in a weird funny way.
> >>>
> >>>May I ask you to avoid to commit features which cause regressions?
> >>
> >>What's broken exactly ?
> >
> >ffplay -vf "movie=0:png:logo.png, scale=100:-1 [logo]; [in][logo] 
> >overlay=10:main_h-overlay_h-10:1 [out]" slow.flv
> >
> >and sorry for the rude reply, now I see that you test only with ffmpeg
> >and not with ffplay (also the fade filter has serious problems when
> >used with ffplay).
> 
> That's ok, it seems you improperly translated to the new API.

100l to me.

> It works fine here now.

Anyway the problem is another one, try with a MPEG video based codec
and you should see. What I'm observing is that the overlay is applied
to the source filter *before* the motion compensation, the
(weird|funny) result is that the logo tends to stain the image
sort-alike ink as the video scrolls.

Regards.
___
FFmpeg-soc mailing list
FFmpeg-soc@mplayerhq.hu
https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc

Re: [FFmpeg-soc] [soc]: r5821 - libavfilter/vf_overlay.c

[Stefano Sabatini]

On date Saturday 2010-06-05 14:02:32 -0700, Baptiste Coudurier encoded:
> Hi Stefano,
> 
> On 6/5/10 6:38 AM, Stefano Sabatini wrote:
> >On date Friday 2010-06-04 22:15:35 +0200, bcoudurier encoded:
> >>Author: bcoudurier
> >>Date: Fri Jun  4 22:15:35 2010
> >>New Revision: 5821
> >>
> >>Log:
> >>Direct rendering in overlay filter.
> >>RGB24 support.
> >>Doesn't work with movie in movie yet, needs loop input feature for logos
> >>either in movie filter or here.
> >
> >Overlay filter is now badly broken in a weird funny way.
> >
> >May I ask you to avoid to commit features which cause regressions?
> 
> What's broken exactly ?

ffplay -vf "movie=0:png:logo.png, scale=100:-1 [logo]; [in][logo] 
overlay=10:main_h-overlay_h-10:1 [out]" slow.flv

and sorry for the rude reply, now I see that you test only with ffmpeg
and not with ffplay (also the fade filter has serious problems when
used with ffplay).

Regards.
___
FFmpeg-soc mailing list
FFmpeg-soc@mplayerhq.hu
https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc

Re: [FFmpeg-soc] [soc]: r5821 - libavfilter/vf_overlay.c

[Stefano Sabatini]

On date Friday 2010-06-04 22:15:35 +0200, bcoudurier encoded:
> Author: bcoudurier
> Date: Fri Jun  4 22:15:35 2010
> New Revision: 5821
> 
> Log:
> Direct rendering in overlay filter.
> RGB24 support.
> Doesn't work with movie in movie yet, needs loop input feature for logos
> either in movie filter or here.

Overlay filter is now badly broken in a weird funny way.

May I ask you to avoid to commit features which cause regressions?

Regards.
___
FFmpeg-soc mailing list
FFmpeg-soc@mplayerhq.hu
https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc

Re: [FFmpeg-soc] [soc]: r5819 - in libavfilter: Makefile allfilters.c vf_fade.c

[Stefano Sabatini]

On date Wednesday 2010-06-02 23:43:50 +0200, bcoudurier encoded:
> Author: bcoudurier
> Date: Wed Jun  2 23:43:50 2010
> New Revision: 5819
> 
> Log:
> Fade filter by Brandon Mintern, rgb support and direct rendering by me
> 
> Added:
>libavfilter/vf_fade.c
> Modified:
>libavfilter/Makefile
>libavfilter/allfilters.c
> 
> Modified: libavfilter/Makefile
> ==
> --- libavfilter/Makefile  Wed May 26 00:54:24 2010(r5818)
> +++ libavfilter/Makefile  Wed Jun  2 23:43:50 2010(r5819)
> @@ -19,6 +19,7 @@ OBJS-$(CONFIG_ASPECT_FILTER)
>  OBJS-$(CONFIG_CROP_FILTER)   += vf_crop.o
>  OBJS-$(CONFIG_DRAWBOX_FILTER)+= vf_drawbox.o
>  OBJS-$(CONFIG_DRAWTEXT_FILTER)   += vf_drawtext.o
> +OBJS-$(CONFIG_FADE_FILTER)   += vf_fade.o
>  OBJS-$(CONFIG_FIFO_FILTER)   += vf_fifo.o
>  OBJS-$(CONFIG_FORMAT_FILTER) += vf_format.o
>  OBJS-$(CONFIG_FPS_FILTER)+= vf_fps.o
> 
> Modified: libavfilter/allfilters.c
> ==
> --- libavfilter/allfilters.c  Wed May 26 00:54:24 2010(r5818)
> +++ libavfilter/allfilters.c  Wed Jun  2 23:43:50 2010(r5819)
> @@ -38,6 +38,7 @@ void avfilter_register_all(void)
>  REGISTER_FILTER (CROP,crop,vf);
>  REGISTER_FILTER (DRAWBOX, drawbox, vf);
>  REGISTER_FILTER (DRAWTEXT,drawtext,vf);
> +REGISTER_FILTER (FADE,fade,vf);
>  REGISTER_FILTER (FIFO,fifo,vf);
>  REGISTER_FILTER (FORMAT,  format,  vf);
>  REGISTER_FILTER (FPS, fps, vf);
> 
> Added: libavfilter/vf_fade.c
> ==
> --- /dev/null 00:00:00 1970   (empty, because file is newly added)
> +++ libavfilter/vf_fade.c Wed Jun  2 23:43:50 2010(r5819)
> @@ -0,0 +1,195 @@
> +/*
> + * video fade filter
> + * copyright (c) 2010 Brandon Mintern
> + * based heavily on vf_negate.c which is copyright (c) 2007 Bobby Bingham
> + *
> + * 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
> + */
> +
> +/*
> + # A few usage examples follow, usable too as test scenarios.
> +
> + # Fade in first 30 frames of video
> + ffmpeg -i input.avi -vfilters fade=in:0:30 output.avi
> +
> + # Fade out last 45 frames of a 200-frame video
> + ffmpeg -i input.avi -vfilters fade=out:155:45 output.avi
> +
> + # Fade in first 25 frames and fade out last 25 frames of a 1000-frame video
> + ffmpeg -i input.avi -vfilters "fade=in:0:25, fade=out:975:25" output.avi
> +
> + # Make first 5 frames black, then fade in from frame 5-24
> + ffmpeg -i input.avi -vfilters "fade=in:5:20" output.avi
> +*/

This goes to user docs, with explanation of all the params.

> +
> +#include "avfilter.h"
> +
> +typedef struct
> +{
> +int factor, fade_per_frame;
> +unsigned int frame_index, start_frame, stop_frame;
> +int hsub, vsub, bpp;
> +} FadeContext;

missing doxies (at least it is required for factor).

> +static av_cold int init(AVFilterContext *ctx, const char *args, void *opaque)
> +{
> +FadeContext *fade = ctx->priv;
> +unsigned int frames;
> +char in_out[4];
> +
> +if(args && sscanf(args, " %3[^:]:%u:%u", in_out,
> +   &fade->start_frame, &frames) == 3) {
> +frames = frames ? frames : 1;
> +fade->fade_per_frame = (1 << 16) / frames;
> +if (!strcmp(in_out, "in"))
> +fade->factor = 0;
> +else if (!strcmp(in_out, "out")) {
> +fade->fade_per_frame = -fade->fade_per_frame;
> +fade->factor = (1 << 16);
> +}

> +else {
> +av_log(ctx, AV_LOG_ERROR,
> +"init() 1st arg must be 'in' or 'out':'%s'\n", in_out);

Such messages are supposed to be exposed to the UI, here it is why I
consider poor practice to use the name of the function (and
inconsistent with the rest of the filters).

> +return -1;
> +}
> +fade->stop_frame = fade->start_frame + frames;
> +return 0;
> +}
> +av_log

Re: [FFmpeg-soc] libavfilter audio work - qualification task

[Stefano Sabatini]

On date Tuesday 2010-05-11 01:12:37 +0200, Stefano Sabatini encoded:
> On date Monday 2010-05-10 15:52:18 -0700, S.N. Hemanth Meenakshisundaram 
> encoded:
> > On 05/10/2010 03:14 PM, Stefano Sabatini wrote:
> > >On date Sunday 2010-05-09 20:42:30 -0700, S.N. Hemanth Meenakshisundaram 
> > >encoded:
> > >>On 05/03/2010 01:32 PM, Stefano Sabatini wrote:
> > >>>On date Monday 2010-05-03 01:11:07 -0700, S.N. Hemanth Meenakshisundaram 
> > >>>encoded:
> > >>>>On 04/23/2010 05:03 PM, Stefano Sabatini wrote:
> > >>>>>On date Thursday 2010-04-22 17:19:16 -0700, S.N. Hemanth 
> > >>>>>Meenakshisundaram encoded:
> > >>>>>[...]
> > >
> > >>+/* FIXME: av_parse_color currently sets alpha to 0 if no alpha is 
> > >>specified.
> > >>+ * So we force alpha = 0xFF (opaque), here in such a case.
> > >>+ */
> > >>+if (rgba[3] != 0)
> > >>+color[3] = rgba[3];
> > >>+else
> > >>+color[3] = 0xFF;
> > >I suppose this was to be skipped.
> > 
> > If I skip this without the parseutils patch, then text specified
> > will be invisible (alpha 0) by default when user specifies
> > foreground color as an english string. So I left it in for the time
> > being. Will remove it along with parseutils patch. Hope that's ok.
> 
> Fine.
> 
> Did you already thought about a syntax? My idea was:
> color/0xXX
> color/DDD
> 
> maybe someone which works with web/design can suggest a more
> familiar/natural syntax though.
>  
> > >Apart those nits patch looks fine to me (but missing configure and
> > >documentation parts), I assume it has been tested and works.
> > 
> > Done. Other nits fixed and the redundant fixme removed. Tested and works.
> > 
> > >Please provide the complete patch.
> > 
> > vf_drawtext.c, allfilter.c and libavfilter Makefile changes are all
> > part of drawtext.diff which is a patch against soc/libavfilter (svn
> > diff ./ in soc/libavfilter directory)
> > 
> > There's no configure in soc/libavfilter, so config.diff is a patch
> > against ffmpeg trunk. Should this be in some other form?
> > 
> > drawtext_doc.diff is a diff with libavfilter.texi of ffmpeg trunk
> > after it has been patched by the checkout.sh script in
> > soc/libavfilter. I can make this a patch to the
> > 03_libavfilter_doc.diff file in soc/libavfilter if required.
> 
> No patch is OK, I think that I'll add a configure patch to soc too.
> 
> If no one else has other comments I'll apply the patch to soc in few
> days.

I had to edit the patch before to apply, there were different warnings
and a problem with the strftime() expansion rendering (only the
characters in the provided string where loaded in init(), that
couldn't work when the string was expanded), please test more
accurately the next time and never ignore warnings.

Also I changed the way the filter is configured, with the applied
patch the --enable-libfreetype switch is required to compile the
drawtext filter. That looks simpler and consistent with the way
configure deals with external libraries.

As for what regards the filter: the outline quality is honestly quite
bad especially at small font sizes, while I really appreciate the
font/box transparency feature :-). Also maybe we should try to add
anti-aliasing support.

Enjoy, regards.
___
FFmpeg-soc mailing list
FFmpeg-soc@mplayerhq.hu
https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc

Re: [FFmpeg-soc] [soc]: r5782 - libavfilter/vf_overlay.c

[Stefano Sabatini]

On date Tuesday 2010-05-11 15:54:21 -0700, Baptiste Coudurier encoded:
> On 05/01/2010 03:44 PM, stefano wrote:
> >Author: stefano
> >Date: Sun May  2 00:44:49 2010
> >New Revision: 5782
> >
> >Log:
> >Make config_input_main() use pixdesc.h for computing chroma offsets
> >and bits per pixel, simplify.
> >
> >Modified:
> >libavfilter/vf_overlay.c
> >
> >Modified: libavfilter/vf_overlay.c
> >==
> >--- libavfilter/vf_overlay.c Sun May  2 00:17:55 2010(r5781)
> >+++ libavfilter/vf_overlay.c Sun May  2 00:44:49 2010(r5782)
> >@@ -26,6 +26,7 @@
> >  #include
> >
> >  #include "avfilter.h"
> >+#include "libavutil/pixdesc.h"
> >  #include "libavcodec/eval.h"
> >  #include "libavutil/avstring.h"
> >
> >@@ -108,28 +109,9 @@ static int config_input_main(AVFilterLin
> >  {
> >  OverlayContext *over = link->dst->priv;
> >
> >-switch(link->format) {
> >-case PIX_FMT_RGB32:
> >-case PIX_FMT_BGR32:
> >-over->bpp = 4;
> >-break;
> >-case PIX_FMT_RGB24:
> >-case PIX_FMT_BGR24:
> >-over->bpp = 3;
> >-break;
> >-case PIX_FMT_RGB565:
> >-case PIX_FMT_RGB555:
> >-case PIX_FMT_BGR565:
> >-case PIX_FMT_BGR555:
> >-case PIX_FMT_GRAY16BE:
> >-case PIX_FMT_GRAY16LE:
> >-over->bpp = 2;
> >-break;
> >-default:
> >-over->bpp = 1;
> >-}
> >-
> >-avcodec_get_chroma_sub_sample(link->format,&over->hsub,&over->vsub);
> >+over->bpp = 
> >(av_get_bits_per_pixel(&av_pix_fmt_descriptors[link->format]) + 7)>>  3;
> >+over->hsub = av_pix_fmt_descriptors[link->format].log2_chroma_w;
> >+over->vsub = av_pix_fmt_descriptors[link->format].log2_chroma_h;
> >
> 
> Humm this seems to break the filter.
> bpp was 1 for yuv before this change, now it is 2.
> bpp is used to offset x from pic->data per component, which seems
> not related to the value av_get_bits_per_pixel returns.

Doh I'm stupid - reverted. That can be achieved in a general/elegant
way using pixdescs, but now it is too late/I'm too tired for that.

Regards.
___
FFmpeg-soc mailing list
FFmpeg-soc@mplayerhq.hu
https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc

Re: [FFmpeg-soc] [RFC] rename vsrc movie to vsrc file

[Stefano Sabatini]

On date Wednesday 2010-05-12 00:10:28 +0200, Vitor Sessak encoded:
> Víctor Paesa wrote:
> >Hi
> >
> >On Tue, May 11, 2010 at 21:46, Vitor Sessak wrote:
> >>Baptiste Coudurier wrote:
> >>>Guys,
> >>>
> >>>What do you think about it ?
> >>Looks a good idea to me, unless someone comes up with an even better name.
> >>
> >
> >Well, strictly speaking, not only files are supported.
> 
> But for me "file" is still the least misleading. For example, in
> "ffmpeg -h":
> 
> >-i filename input file name
> 
> We already call [file|URL|video4windows device number] a "file"...

Exactly. What we're really taking in input is a lavf
resource/source/stream.

Maybe vsrc_stream, but I continue to prefer "lavf" as it is using the
lavf syntax/capabilities.

Regards.
___
FFmpeg-soc mailing list
FFmpeg-soc@mplayerhq.hu
https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc

Re: [FFmpeg-soc] [soc]: r5792 - libavfilter/vf_overlay.c

[Stefano Sabatini]

On date Tuesday 2010-05-11 20:41:13 +0200, bcoudurier encoded:
> Author: bcoudurier
> Date: Tue May 11 20:41:12 2010
> New Revision: 5792
> 
> Log:
> rename parameters name in vf_overlay
> 
> Modified:
>libavfilter/vf_overlay.c
> 
> Modified: libavfilter/vf_overlay.c
> ==
> --- libavfilter/vf_overlay.c  Tue May 11 18:02:29 2010(r5791)
> +++ libavfilter/vf_overlay.c  Tue May 11 20:41:12 2010(r5792)
> @@ -29,10 +29,10 @@
>  #include "libavutil/avstring.h"
>  
>  static const char *var_names[] = {
> -"mainW",///< width of the main video
> -"mainH",///< height of the main video
> -"overlayW", ///< width of the overlay video
> -"overlayH", ///< height of the overlay video
> +"main_w",///< width of the main video
> +"main_h",///< height of the main video
> +"overlay_w", ///< width of the overlay video
> +"overlay_h", ///< height of the overlay video
>  NULL
>  };

Uhm please update docs.

Regards.
___
FFmpeg-soc mailing list
FFmpeg-soc@mplayerhq.hu
https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc

Re: [FFmpeg-soc] [RFC] rename vsrc movie to vsrc file

[Stefano Sabatini]

On date Tuesday 2010-05-11 23:34:34 +0200, Víctor Paesa encoded:
> Hi
> 
> On Tue, May 11, 2010 at 21:46, Vitor Sessak wrote:
> > Baptiste Coudurier wrote:
> >>
> >> Guys,
> >>
> >> What do you think about it ?
> >
> > Looks a good idea to me, unless someone comes up with an even better name.
> >
> 
> Well, strictly speaking, not only files are supported. Maybe "media".

What about vsrc_lavf?

And I posted at some point in the past a vsrc_file source, but that
was doing quite a different thing.

Regards.
___
FFmpeg-soc mailing list
FFmpeg-soc@mplayerhq.hu
https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc

Re: [FFmpeg-soc] libavfilter audio work - qualification task

[Stefano Sabatini]

On date Monday 2010-05-10 15:52:18 -0700, S.N. Hemanth Meenakshisundaram 
encoded:
> On 05/10/2010 03:14 PM, Stefano Sabatini wrote:
> >On date Sunday 2010-05-09 20:42:30 -0700, S.N. Hemanth Meenakshisundaram 
> >encoded:
> >>On 05/03/2010 01:32 PM, Stefano Sabatini wrote:
> >>>On date Monday 2010-05-03 01:11:07 -0700, S.N. Hemanth Meenakshisundaram 
> >>>encoded:
> >>>>On 04/23/2010 05:03 PM, Stefano Sabatini wrote:
> >>>>>On date Thursday 2010-04-22 17:19:16 -0700, S.N. Hemanth 
> >>>>>Meenakshisundaram encoded:
> >>>>>[...]
> >
> >>+/* FIXME: av_parse_color currently sets alpha to 0 if no alpha is 
> >>specified.
> >>+ * So we force alpha = 0xFF (opaque), here in such a case.
> >>+ */
> >>+if (rgba[3] != 0)
> >>+color[3] = rgba[3];
> >>+else
> >>+color[3] = 0xFF;
> >I suppose this was to be skipped.
> 
> If I skip this without the parseutils patch, then text specified
> will be invisible (alpha 0) by default when user specifies
> foreground color as an english string. So I left it in for the time
> being. Will remove it along with parseutils patch. Hope that's ok.

Fine.

Did you already thought about a syntax? My idea was:
color/0xXX
color/DDD

maybe someone which works with web/design can suggest a more
familiar/natural syntax though.
 
> >Apart those nits patch looks fine to me (but missing configure and
> >documentation parts), I assume it has been tested and works.
> 
> Done. Other nits fixed and the redundant fixme removed. Tested and works.
> 
> >Please provide the complete patch.
> 
> vf_drawtext.c, allfilter.c and libavfilter Makefile changes are all
> part of drawtext.diff which is a patch against soc/libavfilter (svn
> diff ./ in soc/libavfilter directory)
> 
> There's no configure in soc/libavfilter, so config.diff is a patch
> against ffmpeg trunk. Should this be in some other form?
> 
> drawtext_doc.diff is a diff with libavfilter.texi of ffmpeg trunk
> after it has been patched by the checkout.sh script in
> soc/libavfilter. I can make this a patch to the
> 03_libavfilter_doc.diff file in soc/libavfilter if required.

No patch is OK, I think that I'll add a configure patch to soc too.

If no one else has other comments I'll apply the patch to soc in few
days.

Regards.
___
FFmpeg-soc mailing list
FFmpeg-soc@mplayerhq.hu
https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc

Re: [FFmpeg-soc] libavfilter audio work - qualification task

[Stefano Sabatini]

On date Sunday 2010-05-09 20:42:30 -0700, S.N. Hemanth Meenakshisundaram 
encoded:
> On 05/03/2010 01:32 PM, Stefano Sabatini wrote:
> >On date Monday 2010-05-03 01:11:07 -0700, S.N. Hemanth Meenakshisundaram 
> >encoded:
> >>On 04/23/2010 05:03 PM, Stefano Sabatini wrote:
> >>>On date Thursday 2010-04-22 17:19:16 -0700, S.N. Hemanth Meenakshisundaram 
> >>>encoded:
> >>>[...]
> >>+
> >>+/* FIXME: av_parse_color currently sets alpha to 0 if no alpha is 
> >>specified.
> >>+ * So we force alpha = 0xFF (opaque), here in such a case.
> >>+ */
> >>+if(rgba[3] != 0)
> >>+color[3] = rgba[3];
> >>+else
> >>+color[3] = 0xFF;
> >>+return 0;
> >>+}
> >What if the user wants to specify alpha = 0?
> >
> >I'd rather avoid the if (... != 0) etc check, the user can set the
> >alpha with the 0xRRGGBBAA syntax if he wants, or we could extend the
> >av_parse_color() syntax for specifing color+alpha (for example:
> >color=red/0xff, a nicer syntax suggestion is welcome).
> 
> Will fix parseutils fix as a separate patch. For now, this will work.
> 
> >
> >So what about:
> >if (alpha) {
> >...
> >} else {
> >...
> >}
> >
> >this should save efficiency if alpha composition is not required. Feel
> >free to skip this and leave it to an eventual further patch.
> 
> Done. Alpha now available for the background box as well.
> 
> >
> >Condition (text == dtext->text) is always true, also we cannot
> >distinguish between the two cases (imho is better like this), and I
> >see no reason to treat '_' in a special way.
> >
> 
> Fixed. '-' is now like any other character.
> 
> Also fixed style nits and corrected handling of freetype error messages.
> 
> >
> >>Index: Makefile
> >
> >>+libavfilter/vf_drawtext.o libavfilter/vf_drawtext.d: CFLAGS += 
> >>$(`freetype-config --cflags`)
> >>+FF_EXTRALIBS += $(`freetype-config --libs`)
> >>+
> >No please, both cflags and ldflags should be set in configure.
> 
> Done. Moved to configure. No changes required now to original Makefile.
> 
> >>--- libavfilter.texi.nodt   2010-05-03 00:39:50.516428954 -0700
> >>+++ libavfilter.texi2010-05-03 00:28:42.221181682 -0700
> >>@@ -148,6 +148,91 @@
> >>  Draw a box with @var{x}:@var{y}:@var{width}:@var{height}:@var{color}
> >>  dimensions in a chosen color.
> >>
> >>+...@section drawtext
> >>+
> >>+Draws text string or text from specified file on top of video.
> >Impersonal form (Draws ->  Draw) seems preferred in libavfilter.texi,
> >same for the parameter descriptions
> 
> Fixed.
> 
> >Nit, add empty newline between @end table and @example, improve
> >readability.
> 
> Done.
> 
> The patch to soc/libavfilter repo is attached. Has changes to
> allfilters.c, libavfilter Makefile and vf_drawtext.c only.
> 
> Please let me know if further changes are required.
> 
> Regards,
> Hemanth
> 

> Index: allfilters.c
> ===
> --- allfilters.c  (revision 5784)
> +++ allfilters.c  (working copy)
> @@ -37,6 +37,7 @@
>  REGISTER_FILTER (ASPECT,  aspect,  vf);
>  REGISTER_FILTER (CROP,crop,vf);
>  REGISTER_FILTER (DRAWBOX, drawbox, vf);
> +REGISTER_FILTER (DRAWTEXT,drawtext,vf);
>  REGISTER_FILTER (FIFO,fifo,vf);
>  REGISTER_FILTER (FORMAT,  format,  vf);
>  REGISTER_FILTER (FPS, fps, vf);
> Index: Makefile
> ===
> --- Makefile  (revision 5784)
> +++ Makefile  (working copy)
> @@ -18,6 +18,7 @@
>  OBJS-$(CONFIG_ASPECT_FILTER) += vf_aspect.o
>  OBJS-$(CONFIG_CROP_FILTER)   += vf_crop.o
>  OBJS-$(CONFIG_DRAWBOX_FILTER)+= vf_drawbox.o
> +OBJS-$(CONFIG_DRAWTEXT_FILTER)   += vf_drawtext.o
>  OBJS-$(CONFIG_FIFO_FILTER)   += vf_fifo.o
>  OBJS-$(CONFIG_FORMAT_FILTER) += vf_format.o
>  OBJS-$(CONFIG_FPS_FILTER)+= vf_fps.o
> Index: vf_drawtext.c
> ===
> --- vf_drawtext.c (revision 0)
> +++ vf_drawtext.c (revision 0)
> @@ -0,0 +1,509 @@
> +/*
> + * copyright (c) 2010 S.N. Hemanth Meenakshisundaram
> + * Original vhook author: Gustavo Sverzut Barbieri 
> + * Libavfilte

Re: [FFmpeg-soc] libavfilter audio work - qualification task

[Stefano Sabatini]

On date Monday 2010-05-03 01:11:07 -0700, S.N. Hemanth Meenakshisundaram 
encoded:
> On 04/23/2010 05:03 PM, Stefano Sabatini wrote:
> >On date Thursday 2010-04-22 17:19:16 -0700, S.N. Hemanth Meenakshisundaram 
> >encoded:
> >[...]
> >>[...]
> >>
> >>4. User now needs to provide only one of text or file, if both are
> >>given then file is used.
> >Uhmmm... this may be a source of errors so not sure it is a good idea,
> >I would prefer to just bail out if both options are used.
> >
> 
> Done. If both options are specified, we bail out now.
> 
> >>10. Updated documentation with new parameter names, strftime
> >>behavior and the file/text requirement.
> >Note: the strfmt syntax may be extended, for example it would be
> >rather useful to be able to print some of the information about the
> >frame/link, e.g. PTS, number of frame, format, size, etc.,
> >this may be done eventually in a further patch...
> 
> I'll add this in a later patch.
> 
> >
> >>As for the alpha channel support in drawbox function, do we need to
> >>update the alpha values? Should the caller be allowed to specify
> >>bgcolor or fgcolor in #RRGGBBAA format?
> >Why not? That would be cool don't you agree? ;-) If looks not trivial
> >skip it, that may be eventually added in a further patch.
> 
> Added alpha support for drawing text and outline but not for the
> background box yet.
> This is simple to do but I would have to start setting each pixel
> instead of one stride at
> a time as is done currently. Is this ok?

Yes, see below comments.
 
> Checking for localtime_r support now and fixed other nits below. All
> the diffs for drawtext are attached at the bottom.
[...] 
> The new diffs follow:

Please for the next times use just a single patch like that produced
by svn diff > patch, this is easier to apply/test (if you're working
on more patches at the same time consider also to use quilt/git, that
should save you some pain).

> Index: allfilters.c
> ===
> --- allfilters.c  (revision 5784)
> +++ allfilters.c  (working copy)
> @@ -37,6 +37,7 @@
>  REGISTER_FILTER (ASPECT,  aspect,  vf);
>  REGISTER_FILTER (CROP,crop,vf);
>  REGISTER_FILTER (DRAWBOX, drawbox, vf);
> +REGISTER_FILTER (DRAWTEXT,drawtext,vf);
>  REGISTER_FILTER (FIFO,fifo,vf);
>  REGISTER_FILTER (FORMAT,  format,  vf);
>  REGISTER_FILTER (FPS, fps, vf);
> Index: Makefile
> ===
> --- Makefile  (revision 5784)
> +++ Makefile  (working copy)
> @@ -18,6 +18,7 @@
>  OBJS-$(CONFIG_ASPECT_FILTER) += vf_aspect.o
>  OBJS-$(CONFIG_CROP_FILTER)   += vf_crop.o
>  OBJS-$(CONFIG_DRAWBOX_FILTER)+= vf_drawbox.o
> +OBJS-$(CONFIG_DRAWTEXT_FILTER)   += vf_drawtext.o
>  OBJS-$(CONFIG_FIFO_FILTER)   += vf_fifo.o
>  OBJS-$(CONFIG_FORMAT_FILTER) += vf_format.o
>  OBJS-$(CONFIG_FPS_FILTER)+= vf_fps.o
> Index: vf_drawtext.c
> ===
> --- vf_drawtext.c (revision 0)
> +++ vf_drawtext.c (revision 0)
> @@ -0,0 +1,498 @@
> +/*
> + * copyright (c) 2010 S.N. Hemanth Meenakshisundaram
> + * Original vhook author: Gustavo Sverzut Barbieri 
> + * Libavfilter version  : S.N. Hemanth Meenakshisundaram 
> + *
> + * 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
> + */
> +
> +/**
> + * @file
> + * Drawtext Filter
> + */
> +
> +#include "avfilter.h"
> +#include "parseutils.h"
> +#include "libavcodec/colorspace.h"
> +#include "libavutil/pixdesc.h"
> +
> +#undef time
> +#include 
> +#include 
> +
> +#inc

Re: [FFmpeg-soc] [PATCH] updated! vf_overlay alpha patch and watermarking using PNG with alpha

[Stefano Sabatini]

On date Thursday 2010-04-29 22:23:38 -0700, Baptiste Coudurier encoded:
> On 2/3/10 4:55 PM, Stefano Sabatini wrote:
> >On date Wednesday 2010-02-03 19:56:12 +0100, Stefano Sabatini encoded:
> >>On date Tuesday 2009-12-01 00:57:59 +0100, Stefano Sabatini encoded:
> >>>On date Tuesday 2009-12-01 00:50:50 +0100, Vitor Sessak encoded:
> >>>>Artur Bodera wrote:
> >[...]
> >>>>>This should save you a lot of time and you can continue to use your 
> >>>>>favorite
> >>>>>transcoder for web video publishing!
> >>>>
> >>>>While I normally oppose making non-committed code more complex, I think
> >>>>this feature is so often requested that it is worth the extra work in
> >>>>the future. Stefano, Michael, any strong opinion about this?
> >>>
> >>>I'm fine with committing the patch to soc if tested, even better would
> >>>be to try to push the filter to the main repo. Does someone want to
> >>>volunteer for this?
> >>
> >>I'll apply the patch soon as this feature is probably the most
> >>requested for lavfi, then I'll work on a proper filter integration
> >>when the lavfi test system will be ready (I hope within a month).
> >
> >Applied, hope this will raise the interest of some wanna-bee
> >contributor ;-)!
> 
> Stefano, can you please apply your cleanup patch in soc svn ?

I should find the time to do it tomorrow (feel free to apply it
yourself if you're in a hurry).

> I intend to work on this.

Cool :-).

Regards.
___
FFmpeg-soc mailing list
FFmpeg-soc@mplayerhq.hu
https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc

Re: [FFmpeg-soc] libavfilter audio work - qualification task

[Stefano Sabatini]

On date Thursday 2010-04-22 17:19:16 -0700, S.N. Hemanth Meenakshisundaram 
encoded:
[...]
> Attached is the vf_drawtext.c and changes to libavfilter.texi (both
> are patches against libavfilter soc like you asked for)
> 
> Following is the list of changes :
> 
> 1. Using a single context structure now. Descriptive variable names.
> 
> 2. Input parameters also are descriptive now, but sometimes
> different from the corresponding context variable where the context
> variable name is too long.
> 
> 3. Using macro instead of function to parse libfreetype messages now.
> 
> 4. Changed warning messages to AV_LOG_WARNINGS.
> 
> 4. User now needs to provide only one of text or file, if both are
> given then file is used.

Uhmmm... this may be a source of errors so not sure it is a good idea,
I would prefer to just bail out if both options are used.

> 5. Made color string to YUV conversion separate function called for
> both fg and bg color.
> 
> 6. Alignments, indents, description of filter and redundant '!='s fixed.
> 
> 7. Reading file only once now in init.
> 
> 8. Using re-entrant localtime_r now.
> 
> 9. The documentation now uses $var{x} instead of ``x''. Made these
> changes throughout the libavfilter doc, not just drawtext. Is that
> ok?

Mmh no we're pretty strict about this, don't worry about the others
I'll fix them tomorrow if I won't be too lazy.

> 10. Updated documentation with new parameter names, strftime
> behavior and the file/text requirement.

Note: the strfmt syntax may be extended, for example it would be
rather useful to be able to print some of the information about the
frame/link, e.g. PTS, number of frame, format, size, etc.,
this may be done eventually in a further patch...
 
> As for the alpha channel support in drawbox function, do we need to
> update the alpha values? Should the caller be allowed to specify
> bgcolor or fgcolor in #RRGGBBAA format?

Why not? That would be cool don't you agree? ;-) If looks not trivial
skip it, that may be eventually added in a further patch.

> Please review and let me know if there's anything else that needs to
> be fixed.
> 
> Regards,
> Hemanth

> Index: vf_drawtext.c
> ===
> --- vf_drawtext.c (revision 0)
> +++ vf_drawtext.c (revision 0)
> @@ -0,0 +1,476 @@
> +/*
> + * copyright (c) 2010 S.N. Hemanth Meenakshisundaram
> + * Original vhook author: Gustavo Sverzut Barbieri 
> + * Libavfilter version  : S.N. Hemanth Meenakshisundaram 
> + *
> + * 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
> + */
> +
> +/**
> + * @file
> + * Drawtext Filter
> + */
> +
> +#include "avfilter.h"
> +#include "parseutils.h"
> +#include "libavcodec/colorspace.h"
> +#include "libavutil/pixdesc.h"
> +
> +#undef time
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +#include FT_FREETYPE_H
> +#include FT_GLYPH_H
> +
> +typedef struct {
> +const AVClass *class;
> +unsigned char *font;
> +unsigned char *text;///< text to be drawn
> +char *file; ///< file with text to be drawn
> +unsigned int x; ///< x position to start drawing text
> +unsigned int y; ///< y position to start drawing text
> +unsigned int size;  ///< font size to use
> +char *fgcolor_string;   ///< foreground color as string
> +char *bgcolor_string;   ///< background color as string
> +unsigned char fgcolor[3];   ///< foreground color in YUV
> +unsigned char bgcolor[3];   ///< background/Box color in YUV
> +short int draw_box; ///< draw box around text - true or false
> +short int outline;  ///< draw outline in bg color around text
> +int text_height;///< height of a font symbol
> +int baseline;   ///< baseline to draw fonts from
> +int use_kerning;///< font kerning is used - true/false
> +FT_Library library; ///< freetype font library handle
> +FT_Face face;   ///< freetype font face handle
> +FT_Glyph glyphs[256];   ///< array holding glyphs of font
> +FT_Bitmap bitmaps[256]; ///< array holding bitma

Re: [FFmpeg-soc] libavfilter audio work - qualification task

[Stefano Sabatini]

On date Friday 2010-04-23 01:50:31 -0700, S.N. Hemanth Meenakshisundaram 
encoded:
> On 04/23/2010 01:09 AM, Víctor Paesa wrote:
> >On Fri, Apr 23, 2010 at 02:19, S.N. Hemanth Meenakshisundaram wrote:
[...]
> >>8. Using re-entrant localtime_r now.
> >Then vf_drawtext should be built only if localtime_r() is available.
> >I think you need to add that dependance into 'configure'.
[...]
> Since time conversion isn't a key function of drawtext, I guess
> localtime_r should be used when present and if not the time format
> parsing code should be compiled off.

I agree. But in this case the user should be warned, something of
the kind:

av_log(ctx, AV_LOG_WARNING, "strformat() expansion unavailable!");

> If that sounds right, I will add the required CC flags.

No need to add CC flags for this, check how it is done for example in
r22684.

Regards.
___
FFmpeg-soc mailing list
FFmpeg-soc@mplayerhq.hu
https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc

Re: [FFmpeg-soc] libavfilter audio work - qualification task

[Stefano Sabatini]

On date Wednesday 2010-04-21 07:55:16 -0700, S.N. Hemanth Meenakshisundaram 
encoded:
[...]
> Also fixed alignment and style wherever non standard. Please review
> and let me know if there's anything else to be fixed. I will now
> work on fixing the corruption in vf_yadif. The complete diff for
> drawtext, documentation, Makefile/allfilters changes is attached
> below.

> Index: allfilters.c
> ===
> --- allfilters.c  (revision 5734)
> +++ allfilters.c  (working copy)
> @@ -37,6 +37,7 @@
>  REGISTER_FILTER (ASPECT,  aspect,  vf);
>  REGISTER_FILTER (CROP,crop,vf);
>  REGISTER_FILTER (DRAWBOX, drawbox, vf);
> +REGISTER_FILTER (DRAWTEXT,drawtext,vf);
>  REGISTER_FILTER (FIFO,fifo,vf);
>  REGISTER_FILTER (FORMAT,  format,  vf);
>  REGISTER_FILTER (FPS, fps, vf);
> Index: diffs/03_libavfilter_doc.diff
> ===
> --- diffs/03_libavfilter_doc.diff (revision 5734)
> +++ diffs/03_libavfilter_doc.diff (working copy)
> @@ -1,8 +1,8 @@
> -Index: doc/libavfilter.texi
> +Index: libavfilter.texi
>  ===
>  doc/libavfilter.texi (revision 22749)
> -+++ doc/libavfilter.texi (working copy)
> -@@ -139,6 +139,20 @@
> +--- libavfilter.texi (revision 22749)
>  libavfilter.texi (working copy)
> +@@ -139,6 +139,101 @@
>   
>   The default value of ``width'' and ``height'' is 0.
>   
> @@ -14,6 +14,87 @@
>  +
>  +Draw a box with x:y:width:height dimensions in a chosen color.
>  +

Please provide a patch against the libavfilter soc trunk, it's so hard
to read a patch of a patch.

> +...@section drawtext
> ++
> ++Draws text string or text from specified file on top of video.
> ++
> ++It accepts the following parameters:
> ++f=:t=:T=:x=:y=:
> ++c=:C=:s=:b=:
> ++o=
> ++
> ++f and t are mandatory parameters.
> ++
> ++The description of the accepted parameters follows.
> ++
> +...@table @option
> +...@item f
> ++
> ++Specifies the font file to be used for drawing text. Path must be included.
> ++This parameter is mandatory.
> ++
> +...@item t
> ++
> ++Specifies the text string to be drawn.
> ++This parameter is mandatory and will be used if no file with text is
> ++specified or if the file fails to open.
> ++
> +...@item T

$var{T}, same for the other vars.

Also I'm never happy about one char variables, think at reading a
script containing such variables, that's why I prefer reasonably short
but *explicative* var names.

> ++
> ++Specifies a text file containing text to be drawn. Max size of 1024
> ++characters.
> ++
> +...@item x, y
> ++
> ++Specify the offsets where text will be drawn within the video
> ++frame. Relative to the top/left border of the output image.
> ++
> ++The default value of ``x'' and ``y'' is 0.

$var{x} and $var{y} (yes the rest of the docs should be updated as
well).

> ++
> +...@item s
> ++
> ++Specifies the font size to be used for drawing text.
> ++
> ++The default value of ``s'' is 16.
> ++
> +...@item c
> ++
> ++Specifies the foreground color to be used for drawing text.
> ++Specify either as a string (e.g. black or as a hex value e.g. FF)
> ++
> ++The default value of ``c'' is black.
> ++
> +...@item C
> ++
> ++Specifies the background color to be used for drawing box around text
> ++or drawing text outline based on option selected.
> ++Specify either as a string (e.g. black or as a 0xRRGGBB e.g. 0xFF)
> ++
> ++The default value of ``C'' is white.
> ++
> +...@item b
> ++
> ++Specifies whether to draw a box around text using background color.
> ++Value should be either 1(enable) or 0(disable).
> ++
> ++The default value of ``b'' is 0.
> ++
> +...@item o
> ++
> ++Specifies whether to draw an outline around text using background color.
> ++Value should be either 1(enable) or 0(disable).
> ++
> ++The default value of ``o'' is 0.
> ++
> +...@end table
> +...@example
> ++./ffmpeg -i in.avi -vfilters drawtext=f=FreeSerif.ttf:t=TestText
> ++:x=100:y=50:s=24:c=Yellow:C=Red:b=1 out.avi
> +...@end example

I generally prefer avoid to mention ff* tools at all, this is the doc
for the filter, the same syntax may be used by a different
library/app.

Also use spaces to improve poor human eye-parsing, I mean something of
the kind:

"drawtext= font=FreeSerif.ttf: text=TestText: x=100: y=50: size=24:
bgcolor=yellow: fgcolor=red : box=1"

> ++
> ++Draw 'TestText' with font FreeSerif of size 24 at (100,50), text color is 
> yellow,
> ++background color is red, draw a box around text.
> ++
>  +...@section fifo
>  +
>  +...@example
> @@ -23,7 +104,7 @@

[...]
> Index: vf_drawtext.c
> ===
> --- vf_drawtext.c (revision 0)
> +++ vf_drawtext.c (revision 0)
> @@ -0,0 +1,510 @@
> +/*
> + * copyright (c) 2010 S.N. Hemanth M

Re: [FFmpeg-soc] libavfilter audio work - qualification task

[Stefano Sabatini]

On date Monday 2010-04-19 00:42:37 -0700, S.N. Hemanth Meenakshisundaram 
encoded:
> On 04/18/2010 07:44 PM, S.N. Hemanth Meenakshisundaram wrote:
> >On 04/18/2010 05:10 PM, Stefano Sabatini wrote:
> >>On date Sunday 2010-04-18 16:10:35 -0700, S.N. Hemanth
> >>Meenakshisundaram encoded:
> >>>On 04/13/2010 12:05 AM, Stefano Sabatini wrote:
> >>>>On date Monday 2010-04-12 22:52:44 -0700, S.N. Hemanth
> >>>>Meenakshisundaram encoded:
> >>>>[...]
> >>>>>I had one (dumb?) question about yadif :
> >>>>>
> >>>>>Since the PicRef structure in libavfilter has no 'fields' member,
> >>>>>how do I find out if the image data in the buffer is
> >>>>>MP_IMGFIELD_ORDERED, MP_IMGFIELD_TOP_FIRST etc. Is it indicated in
> >>>>>the PixelFormat?
> >>>>Ehm no, I believe we need to add it to the AVFilterPicRef struct.
> >>>>
> >>>Hi,
> >>>
> >>>I have a couple more questions :
> >>>
> >>>1. It looks like we output two frames for every input frame/field if
> >>>mode is 1 or 3, else we output a single frame. Is this right?
> >>> From the manual page of mplayer:
> >>
> >>yadif=[mode[:field_dominance]]
> >>   Yet another deinterlacing filter
> >>
> >>   0: Output 1 frame for each frame.
> >>   1: Output 1 frame for each field.
> >>   2: Like 0 but skips spatial interlacing check.
> >>   3: Like 1 but skips spatial interlacing check.
> >>
> >>So yes you look right.
> >>
> >>>2. The mplayer code has a correct_pts variable that seems to allow
> >>>doubling of frame rate. Here is it safe to assume this is always
> >>>allowed/true?
> >>I suppose so, that will also depend on the mode, from what I can
> >>understand you'll need to duplicate the frame rate only with mode 1/3,
> >>this will be done manipulating the output pts.
> >>
> >>>3. If I add a 'fields' member to AVFilterPicRef struct, how do I
> >>>make sure it will be set to the right value (i.e. TOP_FIRST etc)?
> >>It is a problem of the calling application to set this, for example an
> >>application requests a picref with avfilter_get_video_buffer() and
> >>sets the field accordingly. In the case of ffmpeg.c/ffplay.c this
> >>depends on the options set in the codec context or by the user
> >>(e.g. -top_field 1).
> >>
> >>>Thanks
> >>Regards.
> >Thank you. Attached is an initial vf_yadif.c - I have only
> >compiled it yet and will start testing it shortly. A couple of
> >questions :
> >
> >1. I wasn't sure how to modify the header since we wanted to keep
> >yadif under the GPL while the rest of FFmpeg is under the LGPL.

Add:
yadif_filter_deps=gpl

in configure.

> >
> >2. Is the PixelFormat YUV420P equivalent to YV12 or IYUV/I420. The
> >description for YUV420P doesn't seem to say if the 2nd and 3rd
> >planes are VU or UV. Where can I find the other PixelFormat
> >equivalent.

As for the ffmpeg pixfmt ones, you can find a description of each
format in libavutil/pixfmt.h and libavutil/pixdesc.h.

> >
> >Regards,
> 
> Hi,
> 
> Videos do play with vf_yadif in the filter chain, but there are a
> couple of problems right now. Am working on fixing them.
> 
> The first is a memory corruption reported by valgrind :
> 
> ==30358== Conditional jump or move depends on uninitialised value(s)
> ==30358==at 0x418218: filter_line_c (vf_yadif.c:331)
> ==30358==by 0x418762: end_frame (vf_yadif.c:381)
> 
> ==30358==  Uninitialised value was created by a heap allocation
> [...]
> ==30358==by 0x90D187: av_malloc (mem.c:83)
> ==30358==by 0x4183D1: config_props_input (vf_yadif.c:405)
> 
> The offending piece of code seems to be :
> 
> filter_line_c :
> 
> int spatial_score= FFABS(cur[-refs-1] - cur[+refs-1]) + FFABS(c-e)
>  + FFABS(cur[-refs+1] - cur[+refs+1]) - 1;
> 
> #define CHECK(j)\
> {   int score= FFABS(cur[-refs-1+j] - cur[+refs-1-j])\
>  + FFABS(cur[-refs  +j] - cur[+refs  -j])\
>  + FFABS(cur[-refs+1+j] - cur[+refs+1-j]);\
> if(score < spatial_score){\
> spatial_score= score;\
> spatial_pred= (cur[-refs  +j] + cur[+refs  -j])>>1;\
> 
> Line 331: CHECK(-1) CHECK(-2) }} }}
> 
> The allocati

Re: [FFmpeg-soc] libavfilter audio work - qualification task

[Stefano Sabatini]

On date Sunday 2010-04-18 16:10:35 -0700, S.N. Hemanth Meenakshisundaram 
encoded:
> On 04/13/2010 12:05 AM, Stefano Sabatini wrote:
> >On date Monday 2010-04-12 22:52:44 -0700, S.N. Hemanth Meenakshisundaram 
> >encoded:
> >[...]
> >>I had one (dumb?) question about yadif :
> >>
> >>Since the PicRef structure in libavfilter has no 'fields' member,
> >>how do I find out if the image data in the buffer is
> >>MP_IMGFIELD_ORDERED, MP_IMGFIELD_TOP_FIRST etc. Is it indicated in
> >>the PixelFormat?
> >Ehm no, I believe we need to add it to the AVFilterPicRef struct.
> >
> Hi,
> 
> I have a couple more questions :
> 
> 1. It looks like we output two frames for every input frame/field if
> mode is 1 or 3, else we output a single frame. Is this right?

>From the manual page of mplayer:

   yadif=[mode[:field_dominance]]
  Yet another deinterlacing filter
 
  0: Output 1 frame for each frame.
  1: Output 1 frame for each field.
  2: Like 0 but skips spatial interlacing check.
  3: Like 1 but skips spatial interlacing check.

So yes you look right.

> 2. The mplayer code has a correct_pts variable that seems to allow
> doubling of frame rate. Here is it safe to assume this is always
> allowed/true?

I suppose so, that will also depend on the mode, from what I can
understand you'll need to duplicate the frame rate only with mode 1/3,
this will be done manipulating the output pts.

> 3. If I add a 'fields' member to AVFilterPicRef struct, how do I
> make sure it will be set to the right value (i.e. TOP_FIRST etc)?

It is a problem of the calling application to set this, for example an
application requests a picref with avfilter_get_video_buffer() and
sets the field accordingly. In the case of ffmpeg.c/ffplay.c this
depends on the options set in the codec context or by the user
(e.g. -top_field 1).
 
> Thanks

Regards.
___
FFmpeg-soc mailing list
FFmpeg-soc@mplayerhq.hu
https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc

Re: [FFmpeg-soc] libavfilter audio work - qualification task

[Stefano Sabatini]

On date Monday 2010-04-12 22:52:44 -0700, S.N. Hemanth Meenakshisundaram 
encoded:
[...]
> I had one (dumb?) question about yadif :
> 
> Since the PicRef structure in libavfilter has no 'fields' member,
> how do I find out if the image data in the buffer is
> MP_IMGFIELD_ORDERED, MP_IMGFIELD_TOP_FIRST etc. Is it indicated in
> the PixelFormat?

Ehm no, I believe we need to add it to the AVFilterPicRef struct.

Regards.
___
FFmpeg-soc mailing list
FFmpeg-soc@mplayerhq.hu
https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc

Re: [FFmpeg-soc] libavfilter audio work - qualification task

[Stefano Sabatini]

On date Saturday 2010-04-10 18:59:37 -0700, S.N. Hemanth Meenakshisundaram 
encoded:
> On 04/09/2010 04:18 PM, Stefano Sabatini wrote:
[...]
> Please let me know if anything else needs to be fixed.
> 
> Ronald,
> 
> I will use just memcpy instead of fast_memcpy. Is that OK?
> 
> Thanks,

> Index: allfilters.c
> ===
> --- allfilters.c  (revision 5734)
> +++ allfilters.c  (working copy)
> @@ -54,6 +54,7 @@
>  REGISTER_FILTER (SPLIT,   split,   vf);
>  REGISTER_FILTER (TRANSPOSE,   transpose,   vf);
>  REGISTER_FILTER (VFLIP,   vflip,   vf);
> +REGISTER_FILTER (DRAWTEXT,drawtext,vf);

Alphabetical order.
>  
>  REGISTER_FILTER (BUFFER,  buffer,  vsrc);
>  REGISTER_FILTER (MOVIE,   movie,   vsrc);
> Index: diffs/03_libavfilter_doc.diff
> ===
> --- diffs/03_libavfilter_doc.diff (revision 5734)
> +++ diffs/03_libavfilter_doc.diff (working copy)
> @@ -1,8 +1,8 @@
> -Index: doc/libavfilter.texi
> +Index: libavfilter.texi
>  ===
>  doc/libavfilter.texi (revision 22749)
> -+++ doc/libavfilter.texi (working copy)
> -@@ -139,6 +139,20 @@
> +--- libavfilter.texi (revision 22749)
>  libavfilter.texi (working copy)
> +@@ -139,6 +139,30 @@
>   
>   The default value of ``width'' and ``height'' is 0.
>   
> @@ -14,6 +14,16 @@
>  +
>  +Draw a box with x:y:width:height dimensions in a chosen color.
>  +
> +...@section drawtext
> ++
> +...@example
> ++./ffmpeg -i in.avi -vfilters drawtext=font=FreeSerif.ttf:text=TestText
> ++:x=100:y=50:size=24:fgcolor=Yellow:bgcolor=Red:bg=1 out.avi
> +...@end example
> ++
> ++Draw 'TestText' with font FreeSerif of size 24 at (100,50), text color is 
> yellow,
> ++background color is red, draw a box around text.

Please add a table with the meaning of all the parameters. Check the
pad filter documentation to see how.

[...]
> Index: Makefile
> ===
> --- Makefile  (revision 5734)
> +++ Makefile  (working copy)
> @@ -35,6 +35,7 @@
>  OBJS-$(CONFIG_SPLIT_FILTER)  += vf_split.o
>  OBJS-$(CONFIG_TRANSPOSE_FILTER)  += vf_transpose.o
>  OBJS-$(CONFIG_VFLIP_FILTER)  += vf_vflip.o
> +OBJS-$(CONFIG_DRAWTEXT_FILTER)   += vf_drawtext.o

Alphabetical order.

>  OBJS-$(CONFIG_BUFFER_FILTER) += vsrc_buffer.o
>  OBJS-$(CONFIG_MOVIE_FILTER)  += vsrc_movie.o
> Index: vf_drawtext.c
> ===
> --- vf_drawtext.c (revision 0)
> +++ vf_drawtext.c (revision 0)
> @@ -0,0 +1,494 @@
> +/*

> + * vf_drawtext.c: print text over the screen

No need for this, just put the copyright, description may stay in the
@file doxy (also please mention libfreetype in this description).

> + * Original vhook author: Gustavo Sverzut Barbieri 
> + * Libavfilter version  : S.N. Hemanth Meenakshisundaram 
> + *
> + * Example usage with all available options:
> + * ./ffplay -vfilters 
> drawtext=font=FreeSerif.ttf:text=TestText:file=tfil.txt:\
> + *  x=100:y=50:size=24:fgcolor=Yellow:bgcolor=Red:outline=1:bg=1 
> in.avi
> + *
> + * 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
> + */
> +
> +/**
> + * @file libavfilter/vf_drawtext.c
> + * video filter to draw text over screen
> + */
> +
> +#define MAXSIZE_TEXT 1024
> +
> +#include "avfilter.h"
> +#include "parseutils.h"
> +#include "libavutil/pixdesc.h"
> +#include "libavcodec/colorspace.h"

> +#include 
> +#include 

These should be unnecessary.
 
> +#include 
> +#undef time

Why undef time? (I know they were in the vhook filter

Re: [FFmpeg-soc] libavfilter audio work - qualification task

[Stefano Sabatini]

On date Saturday 2010-04-10 01:18:24 +0200, Stefano Sabatini encoded:
> On date Friday 2010-04-09 08:02:50 -0700, S.N. Hemanth Meenakshisundaram 
> encoded:
> > On 04/08/2010 09:54 PM, S.N. Hemanth Meenakshisundaram wrote:
> > >I removed the Makefile changes and added what you suggested above
> > >into the configure script (as in configure.diff).
> > >config.err still showed some errors initially and after tweaking
> > >it a little, the errors stopped. (My headers are in
> > >/usr/include/freetype).
> [...]
> > >Can you give me some pointers on what could be wrong. For the 1st
> > >problem, I tried looking for any other places a new filter needs
> > >to be registered/included and couldn't find any. For the 2nd,
> > >
> > >I am a newbie to configure scripts, so can you please explain what
> > >the configure script lines actually mean.
> 
> For the moment use this:
> 
> --- a/configure
> +++ b/configure
> @@ -2699,6 +2699,8 @@ enabled_any alsa_indev alsa_outdev && check_lib2 
> alsa/asou
>  
>  enabled jack_indev && check_lib2 jack/jack.h jack_client_open -ljack
>  
> +enabled drawtext_filter && add_cflags $(pkg-config --cflags freetype2) && 
> requi
> +

Got mangled, the line to add is:
enabled drawtext_filter && add_cflags $(pkg-config --cflags freetype2) && 
require libfreetype ft2build.h FT_Init_FreeType -lfreetype

Regards.
___
FFmpeg-soc mailing list
FFmpeg-soc@mplayerhq.hu
https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc

Re: [FFmpeg-soc] libavfilter audio work - qualification task

[Stefano Sabatini]

On date Friday 2010-04-09 08:02:50 -0700, S.N. Hemanth Meenakshisundaram 
encoded:
> On 04/08/2010 09:54 PM, S.N. Hemanth Meenakshisundaram wrote:
> >I removed the Makefile changes and added what you suggested above
> >into the configure script (as in configure.diff).
> >config.err still showed some errors initially and after tweaking
> >it a little, the errors stopped. (My headers are in
> >/usr/include/freetype).
[...]
> >Can you give me some pointers on what could be wrong. For the 1st
> >problem, I tried looking for any other places a new filter needs
> >to be registered/included and couldn't find any. For the 2nd,
> >
> >I am a newbie to configure scripts, so can you please explain what
> >the configure script lines actually mean.

For the moment use this:

--- a/configure
+++ b/configure
@@ -2699,6 +2699,8 @@ enabled_any alsa_indev alsa_outdev && check_lib2 alsa/asou
 
 enabled jack_indev && check_lib2 jack/jack.h jack_client_open -ljack
 
+enabled drawtext_filter && add_cflags $(pkg-config --cflags freetype2) && requi
+
 enabled x11grab &&
 check_header X11/Xlib.h &&
 check_header X11/extensions/XShm.h  &&

I have still to think about this /ask to Mans if this is fine (the
problem with this is that the user has to explicitely disable the
drawtext filter if libfreetype is not present), 

> >
> >Thanks,
> >
> Had missed out uninit earlier. Attaching fixed version. From the
> config.err log, it looks like -lfreetype is included and yet the
> linking fails. I tried building a standalone program using freetype
> in the same way and it works. So the freetype libs and include paths
> are ok and something must be going wrong with configure. Could
> someone help me out with a quick way to link in the library directly
> so I can test drawtext for now.
> 
> Thanks
> 

> Index: allfilters.c
> ===
> --- allfilters.c  (revision 5734)
> +++ allfilters.c  (working copy)
> @@ -54,6 +54,7 @@
>  REGISTER_FILTER (SPLIT,   split,   vf);
>  REGISTER_FILTER (TRANSPOSE,   transpose,   vf);
>  REGISTER_FILTER (VFLIP,   vflip,   vf);
> +REGISTER_FILTER (DRAWTEXT,drawtext,vf);
>  
>  REGISTER_FILTER (BUFFER,  buffer,  vsrc);
>  REGISTER_FILTER (MOVIE,   movie,   vsrc);
> Index: Makefile
> ===
> --- Makefile  (revision 5734)
> +++ Makefile  (working copy)
> @@ -35,6 +35,7 @@
>  OBJS-$(CONFIG_SPLIT_FILTER)  += vf_split.o
>  OBJS-$(CONFIG_TRANSPOSE_FILTER)  += vf_transpose.o
>  OBJS-$(CONFIG_VFLIP_FILTER)  += vf_vflip.o
> +OBJS-$(CONFIG_DRAWTEXT_FILTER)   += vf_drawtext.o
>  
>  OBJS-$(CONFIG_BUFFER_FILTER) += vsrc_buffer.o
>  OBJS-$(CONFIG_MOVIE_FILTER)  += vsrc_movie.o
> Index: vf_drawtext.c
> ===
> --- vf_drawtext.c (revision 0)
> +++ vf_drawtext.c (revision 0)
> @@ -0,0 +1,589 @@
> +/*
> + * vf_drawtext.c: print text over the screen
> + 
> **
> + * Options:
> + * -f font filename (MANDATORY!!!)
> + * -s   font size in pixels [default 16]
> + * -b   print background
> + * -o   outline glyphs (use the bg color)
> + * -x  x position ( >= 0) [default 0]
> + * -y  y position ( >= 0) [default 0]
> + * -t text to print (will be passed to strftime())
> + *  MANDATORY: will be used even when -T is used.
> + *  in this case, -t will be used if some error
> + *  occurs
> + * -T file with the text (re-read every frame)
> + * -c <#RRGGBB> foreground color ('internet' way) [default #ff]
> + * -C <#RRGGBB> background color ('internet' way) [default #00]
> + *
> + 
> **
> + * Features:
> + * - True Type, Type1 and others via FreeType2 library
> + * - Font kerning (better output)
> + * - Line Wrap (if the text doesn't fit, the next char go to the next line)
> + * - Background box
> + * - Outline
> + 
> **

User-documentation for filters should be put in doc/libavfilter.texi,
also I don't like this syntax, possibly we should try hard at giving a
consistent interface to the user, so we should either use
PARAM-1:PARAM-2:...:PARAM-N either use libavutil/parseutils.c (which
still depends on opt.c so I don't believe Michail won't accept this to
be included in the main repo, but that's not a problem for now).

> + * Original vhook author: Gustavo Sverzut Barbieri 
> + * Libavfilter version  : S.N. Hemanth Meenakshisundaram 
> + *
> + * Example usage : 
> + * ffmpeg -i input.avi -vfilters \
> + * 'drawtext=f:Ver

Re: [FFmpeg-soc] libavfilter audio work - qualification task

[Stefano Sabatini]

On date Friday 2010-04-09 09:16:01 +0530, Jai Menon encoded:
> On Thu, Apr 1, 2010 at 12:39 AM, Stefano Sabatini
[...]
> > BTW for the students which are not aware of that, there is the afilters
> > repo of the last year GSoC (but badly outdated):
> >
> > svn://svn.mplayerhq.hu/soc/afilters
> >
> > I'm not even sure if it can compile, I'll try to have a look at it and
> > put it in shape in the Easter weekend, thinking at it an audio filter
> > task would be ideal.
> 
> Is there a reason the audio specific code isn't a diff to the current
> lavfi code? I tried looking into it but it just seems like a huge mess
> of mixed up changes. So I really hope you'll have time later :)

Well imo it is simpler to directly work in the avfilters repo, and
move the relevant bits from afilter to avfilters.

Regards.
___
FFmpeg-soc mailing list
FFmpeg-soc@mplayerhq.hu
https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc

Re: [FFmpeg-soc] libavfilter audio work - qualification task

[Stefano Sabatini]

On date Thursday 2010-04-08 08:05:02 -0700, S.N. Hemanth Meenakshisundaram 
encoded:
[...]
> The vf_drawtext filter is almost done but I am having problems
> linking in the freetype libraries. I attempted the attached changes
> to the ffmpeg Makefile but I see the following error :
> 
> ffmpeg/libavfilter/libavfilter.a(vf_drawtext.o): In function `draw_text':
> ffmpeg/libavfilter/vf_drawtext.c:422: undefined reference to
> `FT_Get_Kerning'
> 
> What am I doing wrong?
> 
> Thanks

> Index: Makefile
> ===
> --- Makefile  (revision 22749)
> +++ Makefile  (working copy)
> @@ -71,6 +71,9 @@
>  
>  $(foreach D,$(FFLIBS),$(eval $(call DOSUBDIR,lib$(D
>  
> +libavfilter/vf_drawtext.o libavfilter/vf_drawtext.d: CFLAGS += 
> $(`freetype-config --cflags`)
> +FF_EXTRALIBS += $(`freetype-config --libs`)
> +
>  ffplay_g$(EXESUF): FF_EXTRALIBS += $(SDL_LIBS)
>  ffserver_g$(EXESUF): FF_LDFLAGS += $(FFSERVERLDFLAGS)

I believe the right syntax is: $(shell freetype-config --cflags)

anyway this is not the right way to do it, in configure add something
of the kind:
enabled drawtext_filter && check_lib2 freetype2/freetype.h freetype_init 
-lfreetype
...

drawtext_filter_deps="freetype2_freetype_h"  
drawtext_filter_extralibs="-lfreetype"  

(maybe the last line is not strictly necessary.)

Regards.
___
FFmpeg-soc mailing list
FFmpeg-soc@mplayerhq.hu
https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc

Re: [FFmpeg-soc] libavfilter audio work - qualification task

[Stefano Sabatini]

On date Monday 2010-04-05 19:32:59 +0200, Reimar Döffinger encoded:
> On Mon, Apr 05, 2010 at 07:11:50PM +0200, Stefano Sabatini wrote:
> > > For the deinterlace filter, do we want just a vf_* wrapper for
> > > imgconvert functions or should the code be ported to the
> > > vf_deinterlace filter?
> > 
> > It should be ported, lavfi should not depend on lavc (that is it
> > should be usable without any libavcodec installed).
> 
> Uh, any of the advanced deinterlace filters and some more of MPlayer's
> filters depend on lavc.
> I don't think Michael will accept if you propose to duplicate half the
> snow encoder in lavfi.
> So except for basic functionality I don't see that much point in avoid
> a dependency on lavc if it duplicates more than just a few lines of
> code.

Yes of course some filter may depend on lavc. As for what regards the
deinterlacing implemented in imgconvert.c it looked to me simple
enough to not require to add a dependancy just for that, also I think
that feature (as well as cropping/padding in lavc) is going to be
deprecated.

Regards.
___
FFmpeg-soc mailing list
FFmpeg-soc@mplayerhq.hu
https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc

Re: [FFmpeg-soc] libavfilter audio work - qualification task

[Stefano Sabatini]

On date Monday 2010-04-05 08:44:15 -0700, S.N. Hemanth Meenakshisundaram 
encoded:
> On 04/05/2010 02:43 AM, Stefano Sabatini wrote:
> >On date Thursday 2010-04-01 11:53:42 -0700, Baptiste Coudurier encoded:
> >>On 03/31/2010 10:44 PM, S.N. Hemanth Meenakshisundaram wrote:
> >>>Hi All,
> >>>
> >>>Based on the posts above, here's what I was thinking of doing as a
> >>>qualification task :
> >>>
> >>>1. Fix the configure_filters function in ffmpeg.c to work for both video
> >>>and audio filters.
> >>>
> >>>2. Bring the af_null and af_vol filters from soc/afilters to
> >>>soc/avfilter and generalize avfilter framework to work with the af_*
> >>>filters. This should involve a minimal design for the avfilter audio
> >>>changes.
> >>>
> >>>3. af_vol currently just scales input by two. Modify af_vol to have some
> >>>basic volume filter functionality.
> >>>
> >>>Please let me know if I have understood the tasks right and if this will
> >>>work as a qualification task.
> >I believe that is even too burden as a qualification task, much of the
> >libavfilter audio design has yet to be done.
> >
> >>A qualification task could be to add AVCodecContext get_buffer
> >>functionality to audio decoders.
> >As alternative to this, any video libavfilter task should be OK
> >(e.g. port a filter from MPlayer/libmpcodecs or write a new one), note
> >that vf_imlib.c is *not* a valid qualification task (see
> >https://roundup.ffmpeg.org/issue302), this should help you to get
> >confident with the FFmpeg/libavfilter API.
> >
> >I especially recommend: a deinterlace filter (check the code in
> >libavcodec/imgconvert.c), a libfreetype wrapper (check as reference
> >vhook/drawtext.c in ffmpeg-0.5).
> >
> >Ask here or on IRC if you have questions.
> >
> Hi,
> 
> For the deinterlace filter, do we want just a vf_* wrapper for
> imgconvert functions or should the code be ported to the
> vf_deinterlace filter?

It should be ported, lavfi should not depend on lavc (that is it
should be usable without any libavcodec installed).
 
> I have been working on getting the audio filters from soc/afilters
> to work more like the current video filters and wanted to check that
> am on the right track :
> 
> 1. Client will use a 'asrc_buffer_add_samples' function to give
> buffers to the source input filter or define an input filter that
> can fetch audio data.
> 2. Client then calls request_buffer on output filter,
> request_buffers propagate all the way to source (input filter).
> 3. The buffer is then passed along the filter chain and processed.

Looks fine, BTW also check this thread:
http://thread.gmane.org/gmane.comp.video.ffmpeg.devel/107363

> Also have a couple of questions :
> 
> 1. Should the formats for audio be from the SampleFormat enum
> (libavcodec/avcodec.h) or the PCM formats in the CodecID enum. The
> old audio filter seems to be wrongly using both in two different
> places.

That has to do with how we choose to represent samples. Currently we
should use enum SampleFormat, but as you can see the CODEC_ID_ provide
more information (e.g. CODEC_ID_PCM_F32BE, CODEC_ID_PCM_F32LE,
CODEC_ID_PCM_F64BE, CODEC_ID_PCM_F64LE while we have just a
SAMPLE_FMT_DBL SampleFormat).

Preferably use enum SampleFormat, but be aware that it will need to be
extended (also maybe we will need some sort of sample format
descriptor of the kind of that defined in pixdesc.h, doesn't look
strictly necessary by now though).

> 2. While video filters work a single frame at a time, audio would
> need to work on a buffer. Is it ok to use a single call similar to
> the current 'filter_buffer' to get this done instead of the
> start_frame, draw_slice, end_frame sequence in video?

Yes, check also the abovementioned thread.

> I am planning to do the deinterlace, libfreetype first and then
> continue with this.

Good. Feel free to join the discussion on ffmpeg-devel regarding the
libavfilter API, consider that as part of the qual task.

Regards.
___
FFmpeg-soc mailing list
FFmpeg-soc@mplayerhq.hu
https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc

Re: [FFmpeg-soc] libavfilter audio work - qualification task

[Stefano Sabatini]

On date Thursday 2010-04-01 11:53:42 -0700, Baptiste Coudurier encoded:
> On 03/31/2010 10:44 PM, S.N. Hemanth Meenakshisundaram wrote:
> >
> >Hi All,
> >
> >Based on the posts above, here's what I was thinking of doing as a
> >qualification task :
> >
> >1. Fix the configure_filters function in ffmpeg.c to work for both video
> >and audio filters.
> >
> >2. Bring the af_null and af_vol filters from soc/afilters to
> >soc/avfilter and generalize avfilter framework to work with the af_*
> >filters. This should involve a minimal design for the avfilter audio
> >changes.
> >
> >3. af_vol currently just scales input by two. Modify af_vol to have some
> >basic volume filter functionality.
> >
> >Please let me know if I have understood the tasks right and if this will
> >work as a qualification task.

I believe that is even too burden as a qualification task, much of the
libavfilter audio design has yet to be done.

> A qualification task could be to add AVCodecContext get_buffer
> functionality to audio decoders.

As alternative to this, any video libavfilter task should be OK
(e.g. port a filter from MPlayer/libmpcodecs or write a new one), note
that vf_imlib.c is *not* a valid qualification task (see
https://roundup.ffmpeg.org/issue302), this should help you to get
confident with the FFmpeg/libavfilter API.

I especially recommend: a deinterlace filter (check the code in
libavcodec/imgconvert.c), a libfreetype wrapper (check as reference
vhook/drawtext.c in ffmpeg-0.5).

Ask here or on IRC if you have questions.

Regards.
___
FFmpeg-soc mailing list
FFmpeg-soc@mplayerhq.hu
https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc

Re: [FFmpeg-soc] Help needed with new concatenate filter

[Stefano Sabatini]

On date Sunday 2010-04-04 16:16:28 -0400, Brandon Mintern encoded:
> On Thu, Apr 1, 2010 at 9:03 AM, Stefano Sabatini
>  wrote:
> > On date Wednesday 2010-03-31 20:06:17 -0400, Brandon Mintern encoded:
> >> Thanks a lot for the feedback. A new, much cleaner (and actually
> >> similar to what I wrote on my first try before changing it to what you
> >> saw) patch is at the bottom of this post. I still can't see why the
> >> 2nd input is not being output; it seems like everything should be
> >> getting properly propagated.
> >
> > You need to shift the PTSes of the second source, something of the
> > kind:
> > pts += last_pts_of_first_source;
> 
> I tried to do this in start_frame:
> 
> static void start_frame(AVFilterLink *link, AVFilterPicRef *picref)
> {
> ConcatenateContext *con = link->dst->priv;
> 
> if (con->first_input_consumed)
> picref->pts += con->first_input_last_pts;
> else
> con->first_input_last_pts = picref->pts;
> 
> avfilter_null_start_frame(link, picref);
> }
> 
> 
> first_input_consumed is set in request_frame when the first input
> returns a nonzero number.
> 
> Apparently my approach here is incorrect, because the filter still
> isn't working as I am expecting it to. My current patch is attached if
> anyone is interested in taking a look at what I have.

I don't know how are you testing this, but I suppose you're using
ffplay to test this.

In order to understand what's going on you need to understand the
threading model used by ffplay (hint: from gdb use thread apply all
bt).

The problem here looks like that when the decode thread stops to
process packets, it doesn't send anymore packets to the queue where it
is waiting the video thread.

So the video thread doesn't have a way to signal to the filterchain
that the input source ended, and ffplay will simply stop to play the
video.

Yes maybe this should be fixed in ffplay, patches are welcome of
course :-).

> Thanks for your help,
> Brandon

Regards.

___
FFmpeg-soc mailing list
FFmpeg-soc@mplayerhq.hu
https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc

Re: [FFmpeg-soc] [PATCH] cosmetics, rename variable, parenthese placement

[Stefano Sabatini]

On date Thursday 2010-04-01 12:41:24 -0700, Baptiste Coudurier encoded:
> Hi guys
> 
> $subject.
> 
> What was the decision for passing options to scaler ?

Mmh I believe we have no decision taken, all my proposals got refused,
to be honest I'm the first one which don't like them very much (they
were sort of hacks):

http://thread.gmane.org/gmane.comp.video.ffmpeg.devel/81041/

Having a sane sane hookup *may* need some reworking on how libswscale
deals with options, yes that would need amongst various things to move
eval/opt code to lavu.
 
> Btw, people might want to hook another scaler and use it to "auto
> scale", so it seems needed to choose a generic and simple way.

Yes when possible, but please let's get something good enough and
working and simple and committable, then we can think at extending it.

Regards.
___
FFmpeg-soc mailing list
FFmpeg-soc@mplayerhq.hu
https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc

Re: [FFmpeg-soc] Help needed with new concatenate filter

[Stefano Sabatini]

On date Wednesday 2010-03-31 20:06:17 -0400, Brandon Mintern encoded:
> Thanks a lot for the feedback. A new, much cleaner (and actually
> similar to what I wrote on my first try before changing it to what you
> saw) patch is at the bottom of this post. I still can't see why the
> 2nd input is not being output; it seems like everything should be
> getting properly propagated.

You need to shift the PTSes of the second source, something of the
kind:
pts += last_pts_of_first_source;

[...]

Regards.
___
FFmpeg-soc mailing list
FFmpeg-soc@mplayerhq.hu
https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc

Re: [FFmpeg-soc] Help needed with new concatenate filter

[Stefano Sabatini]

On date Wednesday 2010-03-31 18:00:46 -0400, Brandon Mintern encoded:
> I'm trying to add a filter to concatenate multiple inputs together.
> The idea is that the inputs should already be the same size and frame
> rate, but I don't actually enforce that, I just ensure that the output
> buffer is big enough to hold the biggest height/width. Here is a
> sample usage:
> 
> ./ffmpeg_g -y -i input1.wmv -vfilters "movie=0:wmv3:input2.wmv [in2];
> [in][in2] concatenate" -r 15 out.wmv
> 
> Where input1.wmv and input2.wmv are both 15 fps and 800x600. As
> written now, out.wmv seems to only be input1.wmv. I would appreciate
> any insight into what I'm doing wrong. The patch is located at
> http://bmintern.homeunix.com/~brandon/vf_concatenate.patch and is
> included below.
> 
> Thanks,
> Brandon
> 
> Index: allfilters.c
> ===
> --- allfilters.c  (revision 5726)
> +++ allfilters.c  (working copy)
> @@ -35,6 +35,7 @@
>  initialized = 1;
> 
>  REGISTER_FILTER (ASPECT,  aspect,  vf);
> +REGISTER_FILTER (CONCATENATE, concatenate, vf);
>  REGISTER_FILTER (CROP,crop,vf);
>  REGISTER_FILTER (DRAWBOX, drawbox, vf);
>  REGISTER_FILTER (FIFO,fifo,vf);
> Index: vf_concatenate.c
> ===
> --- vf_concatenate.c  (revision 0)
> +++ vf_concatenate.c  (revision 0)
> @@ -0,0 +1,109 @@
> +/*
> + * video concatenate filter
> + * copyright (c) 2007 Bobby Bingham
> + *
> + * 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
> + */
> +
> +#include "avfilter.h"
> +
> +typedef struct {
> +int first_input_consumed;
> +AVFilterPicRef *pic;
> +} ConcatenateContext;
> +
> +static av_cold void uninit(AVFilterContext *ctx)
> +{
> +ConcatenateContext *con = ctx->priv;
> +if (con->pic)
> +avfilter_unref_pic(con->pic);

This is not the way picref are supposed to be unref-fed. They should
be unref-ed during processing, so this is not needed.

> +}
> +
> +static int config_props(AVFilterLink *link)
> +{
> +if (link->src->inputs[0]->w > link->src->inputs[1]->w)
> +link->w = link->src->inputs[0]->w;
> +else
> +link->w = link->src->inputs[1]->w;
> +if (link->src->inputs[1]->h > link->src->inputs[1]->h)
> +link->h = link->src->inputs[0]->h;
> +else
> +link->h = link->src->inputs[1]->h;
> +return 0;
> +}

Variable video frame size is not supported, that means that something
bad will likely happen when the size of the video will change from the
first to the second source. 

> +
> +static void start_frame(AVFilterLink *link, AVFilterPicRef *picref)
> +{
> +ConcatenateContext *con = link->dst->priv;
> +con->pic = picref;
> +}

You need to propagate the start_frame to the next filter. Also I
suppose your filter is not changing the passed in video frame, so a
simple avfilter_null_start_frame should be enough.

> +static void end_frame(AVFilterLink *link)
> +{
> +}
> +
> +static int poll_frame(AVFilterLink *link)
> +{
> +ConcatenateContext *con = link->src->priv;
> +if (con->first_input_consumed)
> +return avfilter_poll_frame(link->src->inputs[1]);
> +return avfilter_poll_frame(link->src->inputs[0]);
> +}
> +
> +static int request_frame(AVFilterLink *link)
> +{
> +ConcatenateContext *con = link->src->priv;
> +if(!con->first_input_consumed &&
> +   avfilter_request_frame(link->src->inputs[0]))
> +con->first_input_consumed = 1;
> +if(con->first_input_consumed &&
> +   avfilter_request_frame(link->src->inputs[1]))
> +return AVERROR_EOF;

> +avfilter_start_frame(link, con->pic);
> +avfilter_draw_slice(link, 0, con->pic->h, 1);
> +avfilter_end_frame(link);
> +con->pic = NULL;

This can't work, suppose request_frame() is called, it is propagated
to the source, finally the source calls start_frame() but it is not
propagated, then draw_slice() is called, which is propagated (see
avfilter_default_slice()), this will result in a crash.

In other words the rule is:

avfilter_start_frame(), _draw_slice() and _end_frame() must be
propagated in this order from the source to the destination

Re: [FFmpeg-soc] libavfilter audio work - qualification task

[Stefano Sabatini]

On date Thursday 2010-04-01 00:17:28 +0530, Jai Menon encoded:
> On Thu, Apr 1, 2010 at 12:08 AM, Stefano Sabatini
>  wrote:
> 
> [...]
> 
> > As for the qualification task, in the case people don't like the
> > vf_imlib2 port, I suggest a deinterlace/interlace filter which seems
> > needed for video filters integration in ffmpeg, I believe there is
> > something in MPlayer/libmpcodecs which can be used as reference, but
> > as I said anything related to audio/filtering should be OK for showing
> > us if you seem able to accomplish the GSoC task.
> 
> I'm not sure how far along the libavfilter audio scaffolding is but a
> simple volume filter perhaps.

BTW for the student which are not aware of that, there is the afilters
repo of the last year GSoC (but badly outdated):

svn://svn.mplayerhq.hu/soc/afilters

I'm not even sure if it can compile, I'll try to have a look at it and
put it in shape in the Easter weekend, thinking at it an audio filter
task would be ideal.

Regards.
___
FFmpeg-soc mailing list
FFmpeg-soc@mplayerhq.hu
https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc

Re: [FFmpeg-soc] libavfilter audio work - qualification task

[Stefano Sabatini]

On date Wednesday 2010-03-31 19:42:52 +0200, Víctor Paesa encoded:
> Hi,
> 
> On Wed, Mar 31, 2010 at 6:26 PM, S.N. Hemanth Meenakshisundaram wrote:
> > Hi All,
> >
> > I would like to take up the libavfilter audio work for gsoc. What would be a
> > good qualification task for this? The wiki says the mentor is yet to be
> > determined, so am asking on this list. I was thinking of taking up the
> > vf_imlib2 work or Cedric's blending routines from the interesting patches
> > list. Is someone else already working on these or is there a more suitable
> > qualification task I can take up?

I believe any task related to audio and/or filtering is fine.

As for the mentorship, I'm not the most qualified person here for what
regards the audio part, but I'll try to act as mentor if no-one else
will step for that (Vitor?) iff there is agreement on that, otherwise
I'll gladly co-mentor.
 
> vf_imlib2 is an interesting patch (in my not neutral opinion) but it doesn't 
> fit
> the filter development direction.
> And that makes me think you need to read the README in SoC libavfilter
> :-)

I've not a strong opinion on this, but there are very intersting
libraries (e.g. libopencv, libaa, or think at libfestival or libsphynx
for audio) which would make sense to hookup in libavfilter without to
replicate all the functionality in FFmpeg, that would be out of
scope.

As for the qualification task, in the case people don't like the
vf_imlib2 port, I suggest a deinterlace/interlace filter which seems
needed for video filters integration in ffmpeg, I believe there is
something in MPlayer/libmpcodecs which can be used as reference, but
as I said anything related to audio/filtering should be OK for showing
us if you seem able to accomplish the GSoC task.

Good luck!, regards.
___
FFmpeg-soc mailing list
FFmpeg-soc@mplayerhq.hu
https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc

Re: [FFmpeg-soc] Trying to write a new filter but unclear on callback order

[Stefano Sabatini]

On date Tuesday 2010-03-30 17:15:04 -0400, Brandon Mintern encoded:
> On Sat, Mar 27, 2010 at 9:27 AM, Stefano Sabatini
>  wrote:
> > On date Saturday 2010-03-27 07:46:26 -0400, Brandon Mintern encoded:
> >> I'm trying to build a filter called "clone" (as discussed with Vitor
> >> on #ffmpeg-devel). I was modeling my filter after fifo, but apparently
> >> I'm wrong about the callback process (sidenote: a more detailed
> >> explanation in the wiki documentation would be very helpful!). I think
> >> I'm reasonably close with the code I have, but I can't finish it until
> >> I better understand the callback order in the filter chain. I would
> >> appreciate it if someone could point me in the write direction.
> >
> > Quick reply as I don't have much time at this moment: enable the DEBUG
> > symbol in avfilter.c and use -logleve debug, that should show you when
> > every callback is called and understand how the filterchain processing
> > stuff works.
> 
> Thank you for this tip. I made a lot of changes after checking out
> vf_fps.c, tried your DEBUG tip, and the first function I see being
> called is request_frame. This seemed incorrect (shouldn't at least
> init() be called first?), so I added av_log(..., AV_LOG_DEBUG, ...)
> messages to the beginning and end of all my functions. It turns out
> that for some reason, init really isn't being called, which helps
> explain the current Segmentation fault that I'm running into.
> 
> I think that for now I'll move onto something easier (vf_fade.c), but
> if someone wouldn't mind taking a look at what I've done I would
> really appreciate it. I really can't figure out what's wrong now. The
> following patch:
> 
> http://bmintern.homeunix.com/~brandon/vf_clone.patch

I can assure you that init is called.

At this point I recommend you to use gdb, that will make things *lots*
easier.

(I'll have a deeper look at the patch tomorrow evening or later.)
 
> is the result of running "svn diff" against the latest libavfilter
> (revision 5726). I guess if I don't hear anything soon, I'll write a
> simpler "vf_frame.c" which will simply output a single given frame a
> specified number of times (rather than a sequence of frames) and see
> if maybe I can get that working.
> 
> > And thanks for the contribution. BTW if you're a student and
> > interested we have a libavfilter GSoC task just waiting for you, or
> > for any interested student.
> 
> Unfortunately I'm no longer a student. Otherwise I would be *very* interested.

Too bad.

Regards.
___
FFmpeg-soc mailing list
FFmpeg-soc@mplayerhq.hu
https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc

Re: [FFmpeg-soc] G723.1 Frame Parser

[Stefano Sabatini]

On date Tuesday 2010-03-30 17:46:43 +0530, Mohamed Naufal encoded:
> Hi
> 
> Here is the code for a frame parser i wrote for the g723.1 codec as my GSoC
> qualification task
> 
> #include 
> #include "libavutil/intreadwrite.h"
> 
> #include "avcodec.h"
> #include "get_bits.h"
> 
> #define PITCH_MIN18
> #define FRM_LEN  240
> #define SFRM_LEN (FRM_LEN/4)
> #define AD_CB_SIZE_HIGH_RATE 85 ///< 85 entry codebook for Frame6k3s
> #define AD_CB_SIZE_LOW_RATE  170///< 170 entry codebook for
> Frame5k3s
> 
> /*
>  *  G723.1 frame types
>  */
> typedef enum {
> Frame6k3,   ///< 6.3 kbps frame rate
> Frame5k3,   ///< 5.3 kbps frame rate
> FrameSID,///< silence insertion descriptor frame
> FrameUntransmitted

vertical align
> } FrameType;
> 
> typedef enum {
> Rate6k3,
> Rate5k3
> } Rate;
> 
> /*
>  *  G723.1 unpacked data subframe
>  */
> typedef struct {
> uint16_t ad_cb_lag; ///< adaptive codebook lag
> uint16_t pitch_lag;
> uint16_t combined_gain;
> uint16_t pulse_pos;
> uint16_t pulse_sign;
> uint16_t grid_index;
> uint16_t amp_index; ///< for SID frames
> } G723_1_Subframe;
> 
> /*
>  *  G723.1 unpacked data frame
>  */
> typedef struct {
> uint32_t lsp_index;
> G723_1_Subframe subframe[4];
> } G723_1_Frame;
> 
> typedef struct g723_1_context {
> G723_1_Frame frame;
> FrameType cur_frame_type;
> Rate cur_rate;
> int is_bad_frame;
> } G723_1_Context;
> 
> /*
>  * Unpack the frame into parameters

nit: Unpacks ... missing final dot.

>  *
>  * @param p   the context
>  * @param buf pointer to the input buffer
>  * @param buf_sizesize of the input buffer
>  */
> static void unpack_bitstream(G723_1_Context *p, const uint8_t *buf,
>int buf_size)
> {
> GetBitContext gb;
> G723_1_Frame *frame = &p->frame;
> uint32_t temp;
> 
> init_get_bits(&gb, buf, buf_size * 8);
> 
> // Extract frame type and rate info
> p->cur_frame_type = get_bits(&gb, 2);
> 
> if (p->cur_frame_type == FrameUntransmitted)
> return;
> 
> frame->lsp_index = get_bits(&gb, 24);
> 
> if (p->cur_frame_type == FrameSID) {
> frame->subframe[0].amp_index = get_bits(&gb, 6);
> return;
> }
> 
> // Extract the info common to both rates
> p->cur_rate = (p->cur_frame_type == 0) ? Rate6k3 : Rate5k3;
> 
> temp = get_bits(&gb, 7);
> if (temp <= 123) {   // test if forbidden code
> frame->subframe[0].pitch_lag = temp + PITCH_MIN;
> }else {
> p->is_bad_frame  = 1; // transmission error
> return;
> }
> 
> frame->subframe[1].ad_cb_lag  = get_bits(&gb, 2);
> 
> temp = get_bits(&gb, 7);
> if (temp <= 123) {
> frame->subframe[1].pitch_lag = temp + PITCH_MIN;
> }else {

nit++: } else {

here and below.

> p->is_bad_frame = 1;
> return;
> }
> 
> frame->subframe[3].ad_cb_lag  = get_bits(&gb, 2);
> 
> frame->subframe[0].ad_cb_lag  = 1;
> frame->subframe[2].ad_cb_lag  = 1;
> 
> frame->subframe[0].combined_gain = get_bits(&gb, 12);
> frame->subframe[1].combined_gain = get_bits(&gb, 12);
> frame->subframe[2].combined_gain = get_bits(&gb, 12);
> frame->subframe[3].combined_gain = get_bits(&gb, 12);
> 
> frame->subframe[0].grid_index = get_bits(&gb, 1);
> frame->subframe[1].grid_index = get_bits(&gb, 1);
> frame->subframe[2].grid_index = get_bits(&gb, 1);
> frame->subframe[3].grid_index = get_bits(&gb, 1);
> 
> if (p->cur_frame_type == Frame6k3) {
> skip_bits(&gb, 1);  // skip reserved bit
> 
> // Compute pulse_pos index using the 13bit combined position index
> temp = get_bits(&gb, 13);
> frame->subframe[0].pulse_pos = (temp / 90) / 9;
> frame->subframe[1].pulse_pos = (temp / 90) % 9;
> frame->subframe[2].pulse_pos = (temp % 90) / 9;
> frame->subframe[3].pulse_pos = (temp % 90) % 9;
> 
> frame->subframe[0].pulse_pos = (frame->subframe[0].pulse_pos << 16)
> +
>get_bits(&gb, 16);
> frame->subframe[1].pulse_pos = (frame->subframe[1].pulse_pos << 14)
> +
>get_bits(&gb, 14);
> frame->subframe[2].pulse_pos = (frame->subframe[2].pulse_pos << 16)
> +
>get_bits(&gb, 16);
> frame->subframe[3].pulse_pos = (frame->subframe[3].pulse_pos << 14)
> +
>get_bits(&gb, 14);
> 
> frame->subframe[0].pulse_sign = get_bits(&gb, 6);
> frame->subframe[1].pulse_sign = get_bits(&gb, 5);
> frame->subframe[2].pulse_sign = get_bits(&gb, 6);
> frame->subframe[3].pulse_sign = get_bits(&gb, 5);
> }else { // Frame5k3
> frame->subframe[0].pulse_pos  = get_bits(&gb, 12);
> frame->subframe[1].puls

Re: [FFmpeg-soc] Trying to write a new filter but unclear on callback order

[Stefano Sabatini]

On date Saturday 2010-03-27 07:46:26 -0400, Brandon Mintern encoded:
> I'm trying to build a filter called "clone" (as discussed with Vitor
> on #ffmpeg-devel). I was modeling my filter after fifo, but apparently
> I'm wrong about the callback process (sidenote: a more detailed
> explanation in the wiki documentation would be very helpful!). I think
> I'm reasonably close with the code I have, but I can't finish it until
> I better understand the callback order in the filter chain. I would
> appreciate it if someone could point me in the write direction.

Quick reply as I don't have much time at this moment: enable the DEBUG
symbol in avfilter.c and use -logleve debug, that should show you when
every callback is called and understand how the filterchain processing
stuff works.

And thanks for the contribution. BTW if you're a student and
interested we have a libavfilter GSoC task just waiting for you, or
for any interested student.

Regards.

___
FFmpeg-soc mailing list
FFmpeg-soc@mplayerhq.hu
https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc

Re: [FFmpeg-soc] Segmentation Fault when using -vfilters "movie ...; overlay"

[Stefano Sabatini]

On date Thursday 2010-03-25 20:15:27 -0400, Brandon Mintern encoded:
> I am trying to overlay a transparent PNG (using alpha blending) of size 
> 800x600
> on an 11-second wmv file of size 800x600. In doing so, I get a Segmentation
> Fault immediately after the "Press [q] to stop encoding" message comes up.
> 
> I already filed a bug at https://roundup.ffmpeg.org/issue1841 but
> cehoyos (the only responder thus far) said, "Imo, problems with a
> patch from the soc repository should be reported to the ffmpeg-soc
> mailing list."
> 
> I'll provide here all of the information that I have provided so far
> in my bug report.
> 
> The command I executed:
> 
> ffmpeg -y -i intro-base.wmv -vfilters "movie=0:png:title-overlay.png [title];
> [in][title] overlay=0:0:1 [out]" -vcodec wmv2 intro-title.wmv
> 
> I have tried it both with and without the "[out]", with no change. When I omit
> all -vfilters stuff, the command works fine, so I'm quite sure the segfault is
> happening as a result of the libavfilter operations.
> 
> My libavfilter info:
> 
> $ svn info libavfilter
> Path: libavfilter
> URL: svn://svn.ffmpeg.org/soc/libavfilter
> Repository Root: svn://svn.ffmpeg.org/soc
> Repository UUID: 66570020-b32e-0410-962d-e44e8f9afd43
> Revision: 5717
> Node Kind: directory
> Schedule: normal
> Last Changed Author: stefano
> Last Changed Rev: 5717
> Last Changed Date: 2010-03-24 19:25:00 -0400 (Wed, 24 Mar 2010)
> 
> To build ffmpeg with libavfilter, I followed this process:
> http://ubuntuforums.org/showthread.php?t=1438052 (skip down to "Updating to
> latest..." for a quick look at how I'm doing it). I wrote that guide 
> yesterday;
> it's quite possible I'm making a mistake in the build process.
[...] 
> If there's anything else I can provide to help this along, I'd be happy to do
> so. I can upload the 2 sample files somewhere if that will be of assistance.

Can you reproduce the same crash also with ffplay -vfilters "..." (I
cannot). Did you tried with other files or the crash only happens with
that particular file?

In the last case yes, uploading the files somewhere may be of help.

Regards.
___
FFmpeg-soc mailing list
FFmpeg-soc@mplayerhq.hu
https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc

Re: [FFmpeg-soc] [soc]: r5665 - libavfilter/vf_rotate.c

[Stefano Sabatini]

On date Monday 2010-03-15 08:27:01 -0500, Bobby Bingham encoded:
> On Mon, 15 Mar 2010 12:44:32 +0100
> Stefano Sabatini  wrote:
> 
> > On date Sunday 2010-03-14 20:24:34 -0500, Bobby Bingham encoded:
> > > On Sat, 13 Mar 2010 14:55:11 +0100 (CET)
> > > stefano  wrote:
> > > 
> > > > Author: stefano
> > > > Date: Sat Mar 13 14:55:11 2010
> > > > New Revision: 5665
> > > > 
> > > > Log:
> > > > Prevent rotate from calling avfilter_default_draw_slice(), which
> > > > was causing randomic behaviour.
> > > > 
> > > > Only one slice has to be passed to the next filter, in the
> > > > end_frame() callback.
> > > 
> > > Perhaps a better solution is actually to change
> > > av_filter_draw_slice() to not call avfilter_default_draw_slice().
> > > I see three cases:
> > > 
> > > 1. filters like vf_rotate, vf_transpose, etc which only send one
> > > slice at the very end.  These should not call
> > > avfilter_default_draw_slice().
> > > 
> > > 2. filters which do some filtering in their own draw_slice.  These
> > > always override avfilter_default_draw_slice().
> > > 
> > > 3. filters which do not touch the video data: vf_null, vf_setpts,
> > > etc. These can use avfilter_default_draw_slice(), but I think they
> > > are the minority of filters.  They can simply specify
> > > avfilter_default_draw_slice as their draw_slice callback.
> > 
> > I think the semantics for the default callbacks is this:
> > "call the default callback if the callback is not explicitely defined
> > in the filter".
> > 
> > and should be respected for all the types of default_* callbacks.
> 
> That is the way it's has been, but I originally did that with the goal
> of making things easier for filter writers, rather than for
> consistency.  The default callbacks should be what filters are most
> likely to use, and it looks like for draw_slice, a default
> implementation which does nothing is more useful than
> avfilter_default_draw_slice().
> 
> Another idea would be do provide an avfilter_null_draw_slice() so that
> each filter doesn't have to provide its own.

I have no strong opinion but I like the avfilter_null_draw_slice()
idea, as for changing the way avfilter_default_draw_slice() works, I'd
say to wait to have more filters included, then we'll see how that
will be convenient.

[...]

Regards.
___
FFmpeg-soc mailing list
FFmpeg-soc@mplayerhq.hu
https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc

Re: [FFmpeg-soc] [soc]: r5674 - in libavfilter: Makefile allfilters.c vf_aspect.c

[Stefano Sabatini]

On date Tuesday 2010-03-16 08:37:40 -0500, Bobby Bingham encoded:
> On Tue, 16 Mar 2010 08:24:40 -0500
[...]
> BTW, this was vf_null.c that I copied it from.  Looks like that file
> was written by Stefano.  If no one beats me to it, I'll add a copyright
> notice to that one tonight.

I don't feel like that's really worth to have a copyright on that
file, also I like to keep it as simple and bare and zen as possible,
that's even including the copyright notice.

If that bothers you, feel free to add it, using my name or preferably
something more fun.

Regards.
___
FFmpeg-soc mailing list
FFmpeg-soc@mplayerhq.hu
https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc

Re: [FFmpeg-soc] [soc]: r5665 - libavfilter/vf_rotate.c

[Stefano Sabatini]

On date Sunday 2010-03-14 20:24:34 -0500, Bobby Bingham encoded:
> On Sat, 13 Mar 2010 14:55:11 +0100 (CET)
> stefano  wrote:
> 
> > Author: stefano
> > Date: Sat Mar 13 14:55:11 2010
> > New Revision: 5665
> > 
> > Log:
> > Prevent rotate from calling avfilter_default_draw_slice(), which was
> > causing randomic behaviour.
> > 
> > Only one slice has to be passed to the next filter, in the end_frame()
> > callback.
> 
> Perhaps a better solution is actually to change
> av_filter_draw_slice() to not call avfilter_default_draw_slice().
> I see three cases:
> 
> 1. filters like vf_rotate, vf_transpose, etc which only send one slice
> at the very end.  These should not call avfilter_default_draw_slice().
> 
> 2. filters which do some filtering in their own draw_slice.  These
> always override avfilter_default_draw_slice().
> 
> 3. filters which do not touch the video data: vf_null, vf_setpts, etc.
> These can use avfilter_default_draw_slice(), but I think they are the
> minority of filters.  They can simply specify
> avfilter_default_draw_slice as their draw_slice callback.

I think the semantics for the default callbacks is this:
"call the default callback if the callback is not explicitely defined
in the filter".

and should be respected for all the types of default_* callbacks.

BTW, it's great to see you back in action on lavfi!! :-)

Regards.
___
FFmpeg-soc mailing list
FFmpeg-soc@mplayerhq.hu
https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc

Re: [FFmpeg-soc] [PATCH] updated! vf_overlay alpha patch and watermarking using PNG with alpha

[Stefano Sabatini]

On date Wednesday 2010-02-03 19:56:12 +0100, Stefano Sabatini encoded:
> On date Tuesday 2009-12-01 00:57:59 +0100, Stefano Sabatini encoded:
> > On date Tuesday 2009-12-01 00:50:50 +0100, Vitor Sessak encoded:
> > > Artur Bodera wrote:
[...]
> > >> This should save you a lot of time and you can continue to use your 
> > >> favorite
> > >> transcoder for web video publishing!
> > >
> > > While I normally oppose making non-committed code more complex, I think  
> > > this feature is so often requested that it is worth the extra work in  
> > > the future. Stefano, Michael, any strong opinion about this?
> > 
> > I'm fine with committing the patch to soc if tested, even better would
> > be to try to push the filter to the main repo. Does someone want to
> > volunteer for this?
> 
> I'll apply the patch soon as this feature is probably the most
> requested for lavfi, then I'll work on a proper filter integration
> when the lavfi test system will be ready (I hope within a month).

Applied, hope this will raise the interest of some wanna-bee
contributor ;-)!
___
FFmpeg-soc mailing list
FFmpeg-soc@mplayerhq.hu
https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc

Re: [FFmpeg-soc] [PATCH] updated! vf_overlay alpha patch and watermarking using PNG with alpha

[Stefano Sabatini]

On date Tuesday 2009-12-01 00:57:59 +0100, Stefano Sabatini encoded:
> On date Tuesday 2009-12-01 00:50:50 +0100, Vitor Sessak encoded:
> > Artur Bodera wrote:
> >> For those that have given up on ffmpeg and +libavfilter -vhook debacle.
> >>
> >> Here's a "just add water" solution to all your trouble: transparent PNG's
> >> and watermarks in recent ffmpeg compilations.
> >>
> >> I'm attaching a working patch that will enable alpha-transparency in 
> >> overlay
> >> filter. This, on the other hand, will let you use overlay filter to
> >> superimpose a video clip or transparent png watermark on another video. 
> >> This
> >> has been tested with recent revisions of svn://
> >> svn.ffmpeg.org/soc/libavfilter rev. 5387 and ffmpeg rev. 19868 (16 Sep
> >> 2009). Compiled and running under both x86 and x86_64 on linux.
> >>
> >>
> >> Example 1 - insert transparent PNG watermark in bottom left corner of the
> >> video:
> >> -vfilters "movie=0:png:logo.png [wm];[in][wm] 
> >> overlay=10:mainH-overlayH-10:1
> >> [out]"
> >>
> >> Notice the last parameter to overlay ":1" - this enables alpha blending.
> >>
> >>
> >> Example 2 - insert 2 different transparent PNG watermarks (second watermark
> >> on bottom right corner):
> >> -vfilters "movie=0:png:logo.png [wm];movie=0:png:logo2.png [awm];[in][wm]
> >> overlay=10:mainH-overlayH-10:1 [int];[int][awm]
> >> overlay=mainW-overlayW-10:mainH-overlayH-10:1 [out]"
> >>
> >> You could chain and add more overlays this way but the efficiency of such
> >> approach is yet to be tested.
> >>
> >>
> >> This should save you a lot of time and you can continue to use your 
> >> favorite
> >> transcoder for web video publishing!
> >
> > While I normally oppose making non-committed code more complex, I think  
> > this feature is so often requested that it is worth the extra work in  
> > the future. Stefano, Michael, any strong opinion about this?
> 
> I'm fine with committing the patch to soc if tested, even better would
> be to try to push the filter to the main repo. Does someone want to
> volunteer for this?

I'll apply the patch soon as this feature is probably the most
requested for lavfi, then I'll work on a proper filter integration
when the lavfi test system will be ready (I hope within a month).

Regards. 
___
FFmpeg-soc mailing list
FFmpeg-soc@mplayerhq.hu
https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc

Re: [FFmpeg-soc] libavfilter segfault when trying rotate=90 on an iphone 3gs video

[Stefano Sabatini]

On date Wednesday 2010-01-13 16:03:04 -0500, Seth Thomas Rasmussen encoded:
> When trying to do a simple encode of an iPhone 3GS video(shot in
> portrait mode), ffmpeg segfaults. The same command minus the
> application of the filter works fine.
> 
> Example command that fails:
> 
> $ ffmpeg -i iphone.MOV -vfilters rotate=90 rotate.mp4

Fixed, thanks for reporting.
___
FFmpeg-soc mailing list
FFmpeg-soc@mplayerhq.hu
https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc

Re: [FFmpeg-soc] [PATCH] updated! vf_overlay alpha patch and watermarking using PNG with alpha

[Stefano Sabatini]

On date Tuesday 2009-12-01 00:57:59 +0100, Stefano Sabatini encoded:
> On date Tuesday 2009-12-01 00:50:50 +0100, Vitor Sessak encoded:
[...]
> I'm fine with committing the patch to soc if tested, even better would
> be to try to push the filter to the main repo. Does someone want to
> volunteer for this?

A somehow tinied-up version which can be used as a base for SVN
inclusion, I believe we should get rid of the blend parameter, also
the expression evaluation may stay in a successive commit.

Regards.
/*
 * copyright (c) 2007 Bobby Bingham
 *
 * 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
 */

/**
 * @file libavfilter/vf_overlay.c
 * overlay one video on top of another
 */

#include "avfilter.h"
#include "libavcodec/eval.h"
#include "libavutil/avstring.h"
#include "libavutil/pixdesc.h"

static const char *var_names[] = {
"main_w",  ///< width of the main video
"main_h",  ///< height of the main video
"over_w",  ///< width of the overlay video
"over_h",  ///< height of the overlay video
NULL
};

enum var_name {
MAIN_W,
MAIN_H,
OVER_W,
OVER_H,
VARS_NB
};

#define MAIN   0
#define OVER   1
#define PREV   0
#define QUEUED 1

typedef struct {
/** pics[MAIN][0..1]   are pictures for the main image.
 *  pics[OVER][0..1]   are pictures for the overlayed image.
 *  pics[x][PREV  ]are previously output images.
 *  pics[x][QUEUED]are queued, yet unused frames for each input. */
AVFilterPicRef *pics[2][2];

int over_x, over_y;  ///< position of overlayed subpicture
char over_x_expr[256], over_y_expr[256];

int bpp;///< bytes per pixel
int hsub, vsub; ///< chroma subsampling

int blend;
} OverlayContext;

static av_cold int init(AVFilterContext *ctx, const char *args, void *opaque)
{
OverlayContext *over = ctx->priv;

av_strlcpy(over->over_x_expr, "0", sizeof(over->over_x_expr));
av_strlcpy(over->over_y_expr, "0", sizeof(over->over_y_expr));

if (args)
sscanf(args, "%255[^:]:%255[^:]:%d", over->over_x_expr, over->over_y_expr, &over->blend);

return 0;
}

static av_cold void uninit(AVFilterContext *ctx)
{
OverlayContext *over = ctx->priv;
int i, j;

for (i = 0; i < 2; i ++)
for (j = 0; j < 2; j ++)
if (over->pics[i][j])
avfilter_unref_pic(over->pics[i][j]);
}

static int query_formats(AVFilterContext *ctx)
{
OverlayContext *over = ctx->priv;

if (over->blend) {
enum PixelFormat pix_fmts1[] = { PIX_FMT_YUV420P,  PIX_FMT_NONE };
enum PixelFormat pix_fmts2[] = { PIX_FMT_YUVA420P, PIX_FMT_NONE };
AVFilterFormats* inoutFormats = avfilter_make_format_list(pix_fmts1);
AVFilterFormats* blendFormats = avfilter_make_format_list(pix_fmts2);
avfilter_formats_ref(inoutFormats, &ctx->inputs [0]->out_formats);
avfilter_formats_ref(inoutFormats, &ctx->outputs[0]->in_formats);
avfilter_formats_ref(blendFormats, &ctx->inputs [1]->out_formats);
} else {
avfilter_default_query_formats(ctx);
}
return 0;
}

static int config_input_main(AVFilterLink *link)
{
OverlayContext *over = link->dst->priv;

over->bpp = av_get_bits_per_pixel(&av_pix_fmt_descriptors[link->format]) >> 3;
over->hsub = av_pix_fmt_descriptors[link->format].log2_chroma_w;
over->vsub = av_pix_fmt_descriptors[link->format].log2_chroma_h;

return 0;
}

#define EVAL_EXPR(val_, expr_)  \
val_ = ff_eval2((expr = expr_), var_values, var_names,  \
NULL, NULL, NULL, NULL, NULL, &error);  \
if (error)  \
goto fail

static int config_input_overlay(AVFilterLink *link)
{
AVFilterContext *ctx  = link->dst;
OverlayContext  *over = link->dst->priv;
const char *error = NULL, *expr;
double var_values[VARS_NB];

/* Finish the configuration by evaluating the express

Re: [FFmpeg-soc] [PATCH] updated! vf_overlay alpha patch and watermarking using PNG with alpha

[Stefano Sabatini]

On date Tuesday 2009-12-01 00:50:50 +0100, Vitor Sessak encoded:
> Artur Bodera wrote:
>> For those that have given up on ffmpeg and +libavfilter -vhook debacle.
>>
>> Here's a "just add water" solution to all your trouble: transparent PNG's
>> and watermarks in recent ffmpeg compilations.
>>
>> I'm attaching a working patch that will enable alpha-transparency in overlay
>> filter. This, on the other hand, will let you use overlay filter to
>> superimpose a video clip or transparent png watermark on another video. This
>> has been tested with recent revisions of svn://
>> svn.ffmpeg.org/soc/libavfilter rev. 5387 and ffmpeg rev. 19868 (16 Sep
>> 2009). Compiled and running under both x86 and x86_64 on linux.
>>
>>
>> Example 1 - insert transparent PNG watermark in bottom left corner of the
>> video:
>> -vfilters "movie=0:png:logo.png [wm];[in][wm] overlay=10:mainH-overlayH-10:1
>> [out]"
>>
>> Notice the last parameter to overlay ":1" - this enables alpha blending.
>>
>>
>> Example 2 - insert 2 different transparent PNG watermarks (second watermark
>> on bottom right corner):
>> -vfilters "movie=0:png:logo.png [wm];movie=0:png:logo2.png [awm];[in][wm]
>> overlay=10:mainH-overlayH-10:1 [int];[int][awm]
>> overlay=mainW-overlayW-10:mainH-overlayH-10:1 [out]"
>>
>> You could chain and add more overlays this way but the efficiency of such
>> approach is yet to be tested.
>>
>>
>> This should save you a lot of time and you can continue to use your favorite
>> transcoder for web video publishing!
>
> While I normally oppose making non-committed code more complex, I think  
> this feature is so often requested that it is worth the extra work in  
> the future. Stefano, Michael, any strong opinion about this?

I'm fine with committing the patch to soc if tested, even better would
be to try to push the filter to the main repo. Does someone want to
volunteer for this?

Regards.
___
FFmpeg-soc mailing list
FFmpeg-soc@mplayerhq.hu
https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc

Re: [FFmpeg-soc] making moving and zooming effect

[Stefano Sabatini]

On date Thursday 2009-11-05 01:00:54 +0200, Oleksandr Bondar encoded:
> >
> > And thinking harder at it, yes it should be possible to implement a
> > filter cropping a given (eventually variable) area in the input video
> > and scaling it to a fixed output size, for example to implement a Ken
> > Burns effect.
> >
> 
> to get simple version of Ken Burns only overlay effect with dynamic x and y
> coordinates is needed.
> 1. scale video to bigger size then original
> 2. slowly to move video
> 
> Should I take setpts filter as a start point for overlay extending, as it
> has N function in parameter?

Yes, another example:
http://thread.gmane.org/gmane.comp.video.ffmpeg.soc/6020/focus=6027

Regards.
___
FFmpeg-soc mailing list
FFmpeg-soc@mplayerhq.hu
https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc

Re: [FFmpeg-soc] making moving and zooming effect

[Stefano Sabatini]

On date Wednesday 2009-11-04 18:20:10 +0100, Stefano Sabatini encoded:
> On date Wednesday 2009-11-04 17:21:04 +0200, Oleksandr Bondar encoded:
> > Thanks for the response.
> 
> Avoid top-posting on FFmpeg mailing lists, we're trying to resist
> against this (predominant) silly way to reply to text messages.
>  
> > When I got something working will put it here.
> > 
> > Have one more question.
> > 
> > Is it possible to use scale and overlay filters with dynamic values of h:w
> > for scale and x:y for overlay?
> > like it is possible in setpts filter,
> > 'setpts=AVTB/25*(N+0.05*sin(N*2*PI/25))'
> 
> Do you mean as a function of PTS or N?
> 
> For the overlay filter that should be possible by extending it, with
> the scale filter that's going to be more tricky since then you'll have
> a variable output video size, which is currently not managed by
> libavfilter.

And thinking harder at it, yes it should be possible to implement a
filter cropping a given (eventually variable) area in the input video
and scaling it to a fixed output size, for example to implement a Ken
Burns effect.

Regards.
___
FFmpeg-soc mailing list
FFmpeg-soc@mplayerhq.hu
https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc

Re: [FFmpeg-soc] making moving and zooming effect

[Stefano Sabatini]

On date Wednesday 2009-11-04 17:21:04 +0200, Oleksandr Bondar encoded:
> Thanks for the response.

Avoid top-posting on FFmpeg mailing lists, we're trying to resist
against this (predominant) silly way to reply to text messages.
 
> When I got something working will put it here.
> 
> Have one more question.
> 
> Is it possible to use scale and overlay filters with dynamic values of h:w
> for scale and x:y for overlay?
> like it is possible in setpts filter,
> 'setpts=AVTB/25*(N+0.05*sin(N*2*PI/25))'

Do you mean as a function of PTS or N?

For the overlay filter that should be possible by extending it, with
the scale filter that's going to be more tricky since then you'll have
a variable output video size, which is currently not managed by
libavfilter.

[...]

Regards. 
___
FFmpeg-soc mailing list
FFmpeg-soc@mplayerhq.hu
https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc

Re: [FFmpeg-soc] making moving and zooming effect

[Stefano Sabatini]

On date Tuesday 2009-11-03 23:05:52 +0200, Oleksandr Bondar encoded:
> Hello,
> 
> I am creating video web editor where I work on video effects now. Want to
> have effect when few videos change each other by moving and zooming. like
> slideshow on mac.
> 
> As I understand from sources and docs, I need to use transpose and scale,
> may be overlay filters. But I do not how to start with them.

Each filter is documented in doc/libavfilter.texi. And of course there
is the code, and ffplay.c / ffmpeg.c provide the reference examples
for their use in a complete application.
 
> I want to understand how to use filters taking filter source as a doc, but I
> do not understand how to do this for now.

You need a source, check for example libavfilter/movie_src.c.
 
> Please, give me direction and few simple examples of using those filters so
> I can continue and find out how to use avfilters.

Are you suggesting a sample application?

That would be useful for other users as well, if you want to try to
tackle the problem and provide some code I'll try to help / review it
here or on libav-user, then the example could be published on the
multimedia wiki.

Regards.
___
FFmpeg-soc mailing list
FFmpeg-soc@mplayerhq.hu
https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc

Re: [FFmpeg-soc] [PATCH] Implement non-positional parameters parsing and parametric expressions for the crop filter arguments

[Stefano Sabatini]

On date Monday 2009-10-05 02:19:44 +0200, Michael Niedermayer encoded:
> On Sun, Oct 04, 2009 at 10:43:21PM +0200, Stefano Sabatini wrote:
> > Hi,
> > 
> > this greatly boosts the crop filter exressivity.
> > 
> > Regards.
> 
> >  doc/vfilters.texi |   48 +-
> >  libavfilter/vf_crop.c |  120 
> > --
> >  tests/codec-regression.sh |   10 +--
> >  3 files changed, 155 insertions(+), 23 deletions(-)
> > c62412ad839dea362fbf46cb89f6d671c53e35b6  crop-use-parse-opts.patch
> > Index: ffmpeg-vfilters/ffmpeg/doc/vfilters.texi
> > ===
> > --- ffmpeg-vfilters.orig/ffmpeg/doc/vfilters.texi   2009-10-04 
> > 22:21:32.0 +0200
> > +++ ffmpeg-vfilters/ffmpeg/doc/vfilters.texi2009-10-04 
> > 22:38:22.0 +0200
> > @@ -72,11 +72,53 @@
> >  @section crop
> >  
> >  @example
> > -./ffmpeg -i in.avi -vfilters "crop=0:0:-1:240" out.avi
> > +./ffmpeg -i in.avi -vfilters "crop= x=0 : y=0: out_w= in_w/2" out.avi
> >  @end example
> >  
> > -Crop the input video to x:y:width:height.
> > -The -1 in width or height means that dimension in the input video.
> > +Crop the input video.
> > +
> > +Parameters are specified as a list of non-positional key=value pairs
> > +separated by ``:''.
> 
> i like to note that this will lead to rejection of the patch if its
> submitted for inclusion in main svn, like it happened with vf_scale.
> The old syntax is clean and sufficient, the new is a mess.

What you call "mess" is what I call "features".

Having an expressive syntax, which lets for example to specify: "crop
at the center of the input area, an area with in_w/w and in_h/2" is a
feature which I want to support, also I found that syntax quite
readable (being explicit and thus more verbose doesn't necessarily
mean less readable).

Then I agree that the code may be simpler, but that depends on the
libraries.
 
> It is possible to allow optionally specifying the left hand sides, that
> is "x=" but that should not be mandatory and it should not be done now
> but after the current code that IS already fine is in main svn.

Fine to discuss that after integration in SVN.

So I assume is already OK to post a patch to put the crop filter
in SVN?

Regards.
___
FFmpeg-soc mailing list
FFmpeg-soc@mplayerhq.hu
https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc

[FFmpeg-soc] [PATCH] Implement non-positional parameters parsing and parametric expressions for the crop filter arguments

[Stefano Sabatini]

Hi,

this greatly boosts the crop filter exressivity.

Regards.
Index: ffmpeg-vfilters/ffmpeg/doc/vfilters.texi
===
--- ffmpeg-vfilters.orig/ffmpeg/doc/vfilters.texi	2009-10-04 22:21:32.0 +0200
+++ ffmpeg-vfilters/ffmpeg/doc/vfilters.texi	2009-10-04 22:38:22.0 +0200
@@ -72,11 +72,53 @@
 @section crop
 
 @example
-./ffmpeg -i in.avi -vfilters "crop=0:0:-1:240" out.avi
+./ffmpeg -i in.avi -vfilters "crop= x=0 : y=0: out_w= in_w/2" out.avi
 @end example
 
-Crop the input video to x:y:width:height.
-The -1 in width or height means that dimension in the input video.
+Crop the input video.
+
+Parameters are specified as a list of non-positional key=value pairs
+separated by ``:''.
+
+...@table @option
+...@item out_w, out_h
+
+Specify the expressions used for computing width and height (default:
+original width, height). Negative values will results in subtracting
+to the input size. For example the expression ``out_w=-100'' is
+equivalent to ``out_w=in_w-100''.
+
+The expressions can contain the ``in_w'' and ``in_h'' variables which
+contain the values of the input size.
+
+...@item x, y
+
+Specify the expressions used for computing the coordinates of the crop
+area to extract from the input area, with respect to the top/left
+border. If the values are negative, they are subtracted to the maximum
+value they can have, which are respectively ``in_w-out_w'' and
+``in_h-out_h''.
+
+The expressions can contain the ``in_w'' and ``in_h'' variables which
+contain the values of the original size, and the ``out_w'' and
+``out_h'' variables which contain the values of the padded area
+size. Default expressions for both x and y are ``0''.
+
+For example to place the cropped area exactly in the center of the
+input image, use the expressions:
+
+...@example
+crop= out_w=in_w / 2 : out_h=in_h/2 : x=(in_w-out_w)/2 : y=(in_h-out_w)/2
+...@end example
+
+For placing the cropped area near to the bottom right corner use the
+expressions:
+
+...@example
+crop= out_w=in_w / 2 : out_h=in_h/2 : x=in_w : y=out_h
+...@end example
+
+...@end table
 
 @section drawbox
 
Index: ffmpeg-vfilters/ffmpeg/libavfilter/vf_crop.c
===
--- ffmpeg-vfilters.orig/ffmpeg/libavfilter/vf_crop.c	2009-10-04 22:21:32.0 +0200
+++ ffmpeg-vfilters/ffmpeg/libavfilter/vf_crop.c	2009-10-04 22:24:36.0 +0200
@@ -22,9 +22,40 @@
 #include 
 
 #include "avfilter.h"
+#include "parseutils.h"
+#include "libavcodec/eval.h"
+
+static const char *var_names[]= {
+"PI",
+"E",
+"in_w", ///< input width
+"out_w",///< output width
+"in_h", ///< input height
+"out_h",///< output height
+"x",///< x offset
+"y",///< y offset
+NULL
+};
+
+enum var_name {
+PI,
+E,
+IN_W,
+OUT_W,
+IN_H,
+OUT_H,
+X,
+Y,
+VARS_NB
+};
 
 typedef struct
 {
+const AVClass *class;
+char *out_w_expr, *out_h_expr;
+char *x_expr, *y_expr;
+
+double var_values[VARS_NB];
 int  x,  y,  w,  h;
 int cx, cy, cw, ch;
 
@@ -32,33 +63,91 @@
 int hsub, vsub; //< chroma subsampling
 } CropContext;
 
+#define OFFSET(x) offsetof(CropContext, x)
+
+static const AVOption crop_options[] = {
+{"out_w", "set output width expression",  OFFSET(out_w_expr), FF_OPT_TYPE_STRING, 0, CHAR_MIN, CHAR_MAX},
+{"out_h", "set output height expression", OFFSET(out_h_expr), FF_OPT_TYPE_STRING, 0, CHAR_MIN, CHAR_MAX},
+{"x", "set x offset expression",  OFFSET(x_expr), FF_OPT_TYPE_STRING, 0, CHAR_MIN, CHAR_MAX},
+{"y", "set y offset expression",  OFFSET(y_expr), FF_OPT_TYPE_STRING, 0, CHAR_MIN, CHAR_MAX},
+{NULL},
+};
+
+static const char *crop_get_name(void *ctx)
+{
+return "crop";
+}
+
+static const AVClass crop_class = {
+"CropContext",
+crop_get_name,
+crop_options
+};
+
 static av_cold int init(AVFilterContext *ctx, const char *args, void *opaque)
 {
 CropContext *crop = ctx->priv;
 
-/* default parameters */
-crop->x = 0;
-crop->y = 0;
-crop->w = -1;
-crop->h = -1;
+crop->class = &crop_class;
+av_opt_set_defaults2(crop, 0, 0);
+
+crop->var_values[PI] = M_PI;
+crop->var_values[E ] = M_E;
 
-if(args)
-sscanf(args, "%d:%d:%d:%d", &crop->x, &crop->y, &crop->w, &crop->h);
+crop->out_w_expr = av_strdup("in_w");
+crop->out_h_expr = av_strdup("in_h");
+crop->x_expr = av_strdup("0");
+crop->y_expr = av_strdup("0");
+
+if (args && av_set_options_string(crop, args, "=", ":") < 0)
+return -1;
 
 return 0;
 }
 
-static int config_input(AVFilterLink *link)
+static av_cold void uninit(AVFilterContext *ctx)
 {
-CropContext *crop = link->dst->priv;
+CropContext *crop = ctx->priv;
 
-crop->cx = FFMIN(crop->x, link->w - 1);
-crop->cy = FFMIN(crop->y, link->h - 1);
-crop->cw = FFMIN(crop->w, link->w - crop->cx);
-

Re: [FFmpeg-soc] [PATCH]new avfilter vf_logo.c overlaying logo onto video

[Stefano Sabatini]

On date Friday 2009-10-02 13:03:09 +0200, juergen_meiss...@spiegel.de encoded:
>  This is a patch which can easyly be applied to checkout 
> svn://svn.mplayerhq.hu/soc/libavfilter.
> 
> Hopefully it will find a way to the /soc/libavfilter store this time.

Hi, I'll be glad to include it in the soc, but the last time you 
didn't replied to our review:

http://thread.gmane.org/gmane.comp.video.ffmpeg.soc/5897

> Best regards
> 
> Jürgen Meissner 
> stellv. Leiter EDV 
> 
> SPIEGEL-Verlag Rudolf Augstein GmbH & Co. KG 
> Brandstwiete 19 
> 20457 Hamburg 
> Tel: +49 (40) 30 07 - 2137 
> Fax: +49 (40) 30 07 - 85 - 2137
> E-Mail: juergen_meiss...@spiegel.de 
> http://www.spiegel.de 

> Index: allfilters.c
> ===
> --- allfilters.c  (Revision 5405)
> +++ allfilters.c  (Arbeitskopie)
> @@ -40,6 +40,7 @@
>  REGISTER_FILTER(FORMAT,format,vf);
>  REGISTER_FILTER(FPS,fps,vf);
>  REGISTER_FILTER(HFLIP,hflip,vf);
> +REGISTER_FILTER(LOGO,logo,vf);
>  REGISTER_FILTER(NEGATE,negate,vf);
>  REGISTER_FILTER(NOFORMAT,noformat,vf);
>  REGISTER_FILTER(NULL,null,vf);
> Index: diffs/03_libavcodec_filters.diff
> ===
> --- diffs/03_libavcodec_filters.diff  (Revision 0)
> +++ diffs/03_libavcodec_filters.diff  (Revision 0)
> @@ -0,0 +1,12 @@
> +Index: libavcodec/Makefile
> +===
> +--- libavcodec/Makefile  (Revision 20088)
>  libavcodec/Makefile  (Arbeitskopie)
> +@@ -18,6 +18,7 @@
> +opt.o\
> +options.o\
> +parser.o \
> ++   pixdesc.o \
> +raw.o\
> +resample.o   \
> +resample2.o  \
> Index: doc/vfilters.texi
> ===
> --- doc/vfilters.texi (Revision 5405)
> +++ doc/vfilters.texi (Arbeitskopie)
> @@ -117,6 +117,47 @@
>  
>  Flip the video horizontally.
>  
> +...@section logo
> +
> +...@example
> +./ffmpeg -i inputvideofile -vfilters logo=10:20:logofile.png -y 
> outputvideofile
> +...@end example

I'm definitively not fond of positional arguments, I'd prefer rather
something like this:

logo = x= (in_w - logo_w) / 2 : y = (in_h - logo_h) / 2 : filename=logofile.png 

Making x and y function of the in_w, in_h, logo_h and logo_w
expression would greatly add flexibility to the filter.

> + image of logofile.png is overlayed onto every frame of inputvideofile 
> + at offset x=10 y=20 giving outputvideofile
> +
> + x 
> +
> +   Defines a logo (left border) offset from the left side of the video.
> +   A negative value offsets (logo right border) from
> +   the right side of the video.
> +
> + y 
> +
> +   Defines a logo (top border) offset from the top of the video.
> +   A negative value offsets (logo bottom border) from
> +   the bottom of the video.
> +
> + if logofile has no alpha-path You can prefix another 3 fields R,G,B
> + to select a RGB-color to be the transparent one
> +
> + 
> + REMARKS: there is a lot of gymnastics with the single logo frame, we do 
> + this to avoid any transformation for ALL the many 
> + video frames
> +
> +...@example
> +./ffmpeg -i inputvideofile -vfilters logo=0:0:0:10:20:logofile.png -y 
> outputvideofile
> +...@end example
> +
> + black is the color to be understood as transparent
> +
> +...@example
> +./ffmpeg -i inputvideofile -vfilters logo_without_alpha=10:20:logofile.png 
> -y outputvideofile
> +...@end example
> +
> + force overlaying all pixels (even if no alpha-path)
> +
>  @section negate
>  
>  @example
> Index: vf_logo.c
> ===
> --- vf_logo.c (Revision 0)
> +++ vf_logo.c (Revision 0)
> @@ -0,0 +1,852 @@
> +#define VF_LOGO_VERSION "0.9.9 2.10.2009"

No need for version.

> +/**
> + * libavfilter/vf_logo.c
> + * filter to overlay (with or without alpha) logo on top of video
> + * Copyright (c) 2009 Juergen Meissner (using parts of previous code)
> + * Copyright (c) 2008 Victor Paesa (libavfilter/vsrc_movie.c)
> + * Copyright (c) 2007 Bobby Bingham(libavfilter/vf_overlay.c)
> + * Copyright (c) 2007 Juergen Meissner (vhook/overlay.c)
> + *
> + * 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 i

Re: [FFmpeg-soc] libavfilter status

[Stefano Sabatini]

On date Monday 2009-09-28 10:47:07 +0300, Maksym Veremeyenko encoded:
> Stefano Sabatini написав(ла):
>> On date Sunday 2009-09-27 20:09:26 +0300, Maksym Veremeyenko encoded:
>>> Stefano Sabatini написав(ла):
>>> [...]
>>>> As for the current status:
>>>> http://thread.gmane.org/gmane.comp.video.ffmpeg.devel/93176/focus=93336
>>> Any plans for new attempts to submit avfilter to main svn?
>>> There is still no replacements for vhook
>>
>> I'm working on it, unluckily I've not gone too far in these days, but
>> at least there is the regression test for lavfi already committed to
>> the main repo.
>>
>> Anyway help is welcome, for example for each one of the missing points
>> mentioned in the mail.
> There is MANDATORY list of changes required avfilter to include to main  
> svn repo?
> Thread discuss a lot of features and wishes for avfilter but no real  
> MANDATORY list that Baptiste Coudurier asked for was found (IMHO)...

Michael has the final word for what is considered MANDATORY, but
basing on that thread I would say we still miss at least:

* the pad filter
* the scale filter completed
* variable size video frames support

Maybe Michael may also want direct rendering support, each filter
should have one or more corresponding meaningful regression tests
implemented.

Regards.
___
FFmpeg-soc mailing list
FFmpeg-soc@mplayerhq.hu
https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc

Re: [FFmpeg-soc] libavfilter status

[Stefano Sabatini]

On date Sunday 2009-09-27 20:09:26 +0300, Maksym Veremeyenko encoded:
> Stefano Sabatini написав(ла):
> [...]
>> As for the current status:
>> http://thread.gmane.org/gmane.comp.video.ffmpeg.devel/93176/focus=93336
>
> Any plans for new attempts to submit avfilter to main svn?
> There is still no replacements for vhook

I'm working on it, unluckily I've not gone too far in these days, but
at least there is the regression test for lavfi already committed to
the main repo.

Anyway help is welcome, for example for each one of the missing points
mentioned in the mail.

Regards.
___
FFmpeg-soc mailing list
FFmpeg-soc@mplayerhq.hu
https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc

Re: [FFmpeg-soc] libavfilter status

[Stefano Sabatini]

On date Friday 2009-09-25 11:21:37 +0300, Maksym Veremeyenko encoded:
> Hi,
>
> What is current status of *libavfilter*?
>
> Any hope it will be included into main tree?
>
> *vhook* is dropped, *libavfilter* is incomplete (it seems skeleton only)  
> in main tree...

As for the current status:
http://thread.gmane.org/gmane.comp.video.ffmpeg.devel/93176/focus=93336

Regards.
___
FFmpeg-soc mailing list
FFmpeg-soc@mplayerhq.hu
https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc

Re: [FFmpeg-soc] Backup mentor

[Stefano Sabatini]

On date Saturday 2009-08-08 06:46:14 +0200, Vitor Sessak encoded:
> Hi,
>
> This sunday I'll taking a couple of week of vacation. Since I'm  
> mentoring Kevin, it would be great if someone could help him in case he  
> has a question during this period. I've already asked it in the  
> (private) FFmpeg-mentors list to no avail. Could any experienced ffmpeg  
> dev do me this favor?

I'll try to help at least in the next week, then I'll be missing for
some time.

Enjoy your well deserved vacation! ;-)
___
FFmpeg-soc mailing list
FFmpeg-soc@mplayerhq.hu
https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc

Re: [FFmpeg-soc] AAC Encoding - Where we stand, what's left

[Stefano Sabatini]

On date Thursday 2009-07-09 04:49:20 +0200, Michael Niedermayer encoded:
> On Wed, Jul 08, 2009 at 10:19:32PM -0400, Justin Ruggles wrote:
> > Michael Niedermayer wrote:
> > > On Wed, Jul 08, 2009 at 02:55:54PM -0700, Baptiste Coudurier wrote:
> > >> On 07/08/2009 02:06 PM, Michael Niedermayer wrote:
> > >>> On Wed, Jul 08, 2009 at 01:41:52PM -0700, Baptiste Coudurier wrote:
> >  Hi Michael,
> > 
> >  On 07/08/2009 12:28 PM, Michael Niedermayer wrote:
> > > On Wed, Jul 08, 2009 at 01:12:20AM -0400, Alex Converse wrote:
> > >
> > > [...]
> > >
> > > Also if you need (per codec) options as you said, tell me which, ill 
> > > add
> > > them
> >  Do you have a per codec option system ready ? :)
> > >>> no, i need a list of requirements/goals/use cases first
> > >>> once i know what the system should do that AVCodecContext fields cannot,
> > >>> iam sure it shouldnt be that hard ...
> > >> What's needed:
> > >>
> > >> is custom options for encoders/decoders/muxers/demuxers which are only 
> > >> needed for one element.
> > >>
> > >> The idea of using AVCodecContext/AVFormatContext doesn't please some 
> > >> devs 
> > >> it seems (including Justin, Alex, and me).
> > >>
> > >> Of course global values used by all must be put in the global context.
> > >>
> > >> I think _devs_ would like to be able to have custom options not fitting 
> > >> everywhere else without poluting global context. This would also permit 
> > >> to 
> > >> have x264 and lame mapped commandlines options.
> > >>
> > >> Can this request be considered ?
> > > 
> > > yes, i just need to understand what people really want and why.
> > > Heres a try, thats different from what we do now and also is similar to it
> > > 
> > > give each codec/(de)muxer a foobar_opts.h file that lists its custom 
> > > options
> > > and then put
> > > 
> > > #include "foobar_opts.h" inside AVCodecContext from avcodec.h
> > > 
> > > At a binary level its exactly the same, it also makes moving between 
> > > custom
> > > and global options very easy, and it adds more seperation to the 
> > > astronomic
> > > AVCodecContext.
> > 
> > Could we move current global options that are only used by 1 codec into
> > custom options at the next major version bump?
> 
> If the maintainer of that codec would request it and the option is belived
> to be specific to just that codec, i mean not an option that we just dont
> support for other codecs yet ...
> 
> 
> > 
> > I understand about adding fields to AVCodecContext with #include, but I
> > don't quite get how AVOption would fit in?  Would there be a custom
> > AVOption array added to AVCodec?  Or would they all have to go under the
> > global options[]?
> 
> global options, though they could use a similar #include system
> 
> 
> > 
> > Would there be a way for ffmpeg -h to indicate custom options in some
> > way or say what AVCodec they belong to?  Or would that have to be
> > appended to the AVOption help text?
> 
> it would have to be appended to the help text in the very basic suggestion
> i had in mind
> 
> 
> > 
> > > Does that look better to (Justin, Alex, and you) ?
> > > If not please all 3 of you be as elaborate as possible about what is good
> > > and bad on it
> > 
> > One minor downside could be name conflicts between codecs for custom
> > options that do different things.  But that would just have to be
> > avoided with careful and specific naming.
> 
> name conflicts like you describe can only happen when the names are
> exreemly poorly choosen
> 
> 
> > 
> > It also does not seem to allow for the case where a global option would
> > be appropriate because of shared functionality, but where different
> > codecs need to have different default/min/max values or help text.
> 
> My gut feeling says a different help text is indication of serious missuse
> of something.
> About min/max, no my suggestion does not touch these at all
> 
> Also instead of the #includes we could simply change avcodec.h to just
> group all options that are related to one codec together and add appropriate
> comments. This would also be nicer if we consider the global options[] array
> ...
> 
> About per codec min/max i need to think more but at first it seems a seperate
> issue

Maybe you may have a look at my mail "[RFC] New option system", it
should provide the required level of configurability, there is also a
patch by Art regarding per-codec options (let to define a specific
AVOption/AVClass context for every codec).

Regards.
___
FFmpeg-soc mailing list
FFmpeg-soc@mplayerhq.hu
https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc

Re: [FFmpeg-soc] [soc]: r4399 - in afilters: Makefile.dummy af_null.c avfilter.c avfilter.h dummy.c

[Stefano Sabatini]

On date Tuesday 2009-06-09 07:00:29 +0200, kdub encoded:
> @@ -497,6 +516,11 @@ struct AVFilterLink
>  
>  AVFilterPicRef *cur_pic;
>  AVFilterPicRef *outpic;
> +
> +/** the audio buffer reference is sent accross the link by the source. */
> +AVFilterSamplesRef *srcbuf;
> +AVFilterSamplesRef *cur_buf;
> +AVFilterSamplesRef *outbuf;
>  };

I know that this is as in vfilters, but what's the point of having
cur_buf with that underscore (i.e. wy not curbuf)?

Would be OK to change:
cur_pic -> curpic

(or the other way round, that is:
outpic  -> out_pic
srcpic  -> src_pic)?

Regards.
___
FFmpeg-soc mailing list
FFmpeg-soc@mplayerhq.hu
https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc

Re: [FFmpeg-soc] [soc]: r4390 - in afilters: Makefile.dummy af_null.c avfilter.c avfilter.h dummy.c

[Stefano Sabatini]

On date Monday 2009-06-08 22:17:51 +0200, Vitor Sessak encoded:
> kdub wrote:
[...]
>>  /**
>>   * Adds a new reference to a picture.
>>   * @param ref   an existing reference to the picture
>> @@ -345,6 +359,17 @@ struct AVFilterPad
>>   * and another value on error.
>>   */
>>  int (*config_props)(AVFilterLink *link);
>> +
>> +
>> +/**
>> + * Process an audio buffer. This function is where the audio filter 
>> should

ProcessES, third person is preferred, also please don't forget the
final dot in sentences.

>> + * recieve and process data
>
> recEIve
>
>> + */
>> +int (*start_buffer)(AVFilterLink *link);
>> +
>> +int (*end_buffer)(AVFilterLink *link);
>> +
>> +
>>  };
>
> @Michael: If you are going to complain of having start_buffer() for  
> audio and start_frame() for video, this it the best time for it.

We're still in time to change:
start_frame -> start_video_frame
start_buffer -> start_audio_buffer

or maybe apply some better solution (I'm just wondering then how are
we going to name the Subtitle/Text functions...).

Regards.
___
FFmpeg-soc mailing list
FFmpeg-soc@mplayerhq.hu
https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc

Re: [FFmpeg-soc] [RFC] Apply function to pixel filter: vf_applyfn

[Stefano Sabatini]

On date Monday 2009-05-25 15:47:59 +0200, ze...@customsoft.nl encoded:
> 
> Hi, 
> 
> ----- "Stefano Sabatini"  wrote: 
> > I believe pow *is* supported out of the box by the eval code. 
> 
> It is not enabled in the parse_primary(Parser *p) function.
> 
> > Docs and example go to doc/vfilters.texi. 
> 
> Removed them.

Uh, what about to move them to doc/vfilters.texi?
 
> > enum VarName { 
> > ... 
> > VARS_NB 
> > }; 
> > 
> > is better. 
> 
> Done.
> 
> > 
> > And a PTS var may be useful too. 
> > 
> 
> Working on that.
> 
> > > +static const char *applyfn_symbols[POV_NULL+1]={ 
> >   ^^ 
> > Why +1? 
> 
> I copied the code from vf_setpts, didn't gave it second thought. 
> 
> > > +ApplyfnContext *applyfn = ctx->priv;
> > > +char Y_expr[256], U_expr[256], V_expr[256], A_expr[256];
> > > +   const char *error;
> > 
> > Weird indent. 
> > 
> 
> Fixed.
> 
> > > + sscanf(args, "%255[^:]:%255[^:]:%255[^:]:%255[^:]", Y_expr, U_expr, 
> > > V_expr, A_expr) 
> > 
> > I believe here it would be nice to use av_set_options_string, check 
> > vf_pad.c in the archive for an usage example. 
> 
> Done.
> 
> > > +applyfn->value_V = ff_parse(V_expr, applyfn_symbols,
> > > +NULL, NULL, NULL, NULL, &error);
> > > +if (!applyfn->value_V )
> > > +av_log(ctx, AV_LOG_ERROR,
> > > +   "init() cannot parse V expression due to %s\n", 
> > > error);
> > > +
> > > +applyfn->value_A = ff_parse(A_expr, applyfn_symbols,
> > > +NULL, NULL, NULL, NULL, &error);
> > > +if (!applyfn->value_A )
> > > +av_log(ctx, AV_LOG_ERROR,
> > > +   "init() cannot parse A expression due to %s\n", 
> > > error);
> > This can be factorized (check again vf_pad.c to see how), maybe even a 
> > macro may be used. 
> 
> I created a macro for it, I'm not sure if it is okay according to 
> FFmpeg coding standards.
> 
> > > +static void draw_slice(AVFilterLink *link, int y, int h)
> > > +{
> > > +ApplyfnContext *applyfn = link->dst->priv;
> > > +AVFilterPicRef *in  = link->cur_pic;
> > > +AVFilterPicRef *out = link->dst->outputs[0]->outpic;
> > > +uint8_t *inrow_0, *outrow_0, *alpharow, *outrow_1, *outrow_2, 
> > > *inrow_1, *inrow_2;
> > > +int i, j, i_sub, j_sub, outrow_1_off, outrow_2_off, inrow_1_off, 
> > > inrow_2_off;
> > > +
> > > +applyfn->values[POV_N] += 1.0;
> > 
> > Ouch, this is wrong, as draw_slice() is called for every slice(), and 
> > you don't know how many slices there are. This update should be done 
> > in start_frame() / end_frame() (same for W and H, since they're not 
> > supposed to change between a slice and another one). 
> > 
> 
> Moved the code to start_frame. 
> 
> For some functions it would be much easier to normalize the YUV values
> to [0.0..1.0][-0.5..0.5][-0.5..0.5] beforehand, would it be an addition 
> if this were to be an option? 

Yes, I believe so. Maybe simply adding some vars for the normalized
values will be fine.

> Thanks for the feedback!
> 
> Zeger Knops

> Index: vf_applyfn.c
[...]
> +static void draw_slice(AVFilterLink *link, int y, int h)
> +{
> +ApplyfnContext *applyfn = link->dst->priv;
> +AVFilterPicRef *in  = link->cur_pic;
> +AVFilterPicRef *out = link->dst->outputs[0]->outpic;
> +uint8_t *inrow_0, *outrow_0, *alpharow, *outrow_1, *outrow_2, *inrow_1, 
> *inrow_2;
> +int i, j, i_sub, j_sub, outrow_1_off, outrow_2_off, inrow_1_off, 
> inrow_2_off;
> +
> +inrow_0  = in-> data[0] + y * in-> linesize[0];
> +outrow_0 = out->data[0] + y * out->linesize[0];
> +
> +outrow_1_off = (y >> applyfn->vsub)  * out->linesize[1];
> +outrow_2_off = (h >> applyfn->vsub ) * out->linesize[2] * ( link->w >> 
> applyfn->hsub ) * (y >> applyfn->vsub);
> +inrow_1_off  = (y >> applyfn->vsub)  * in-> linesize[1];
> +inrow_2_off  = (h >> applyfn->vsub ) * in-> linesize[2] * ( link->w >> 
> applyfn->hsub ) * (y >> applyfn->vsub);
> +
> +outrow_1 = outrow_1_off + out->data[1];
> +outrow_2 = outro

Re: [FFmpeg-soc] [RFC] Apply function to pixel filter: vf_applyfn

[Stefano Sabatini]

On date Sunday 2009-05-24 20:19:34 +0200, ze...@customsoft.nl encoded:
> Hi,
> 
> A lot of image operations like gamma adjustment, color inversion or
> contrast enhancement can be expressed as a simple function applied 
> to each pixel. I have written a YUV(A) only filter to apply these
> functions.
> 
> For example: color inversion becomes applyfn=255-Y:255-U:255-V.
> If the pow function would be available a gamma correction would 
> look like this: applyfn=255*pow(Y/255\,0.25):U:V

I believe pow *is* supported out of the box by the eval code.
 
> Zeger Knops
> Index: Makefile
> ===
> --- Makefile(revision 4305)
> +++ Makefile(working copy)
> @@ -14,6 +14,7 @@
> parseutils.o \
>  
>  
> +OBJS-$(CONFIG_APPLYFN_FILTER)+= vf_applyfn.o
>  OBJS-$(CONFIG_CROP_FILTER)   += vf_crop.o
>  OBJS-$(CONFIG_DRAWBOX_FILTER)+= vf_drawbox.o
>  OBJS-$(CONFIG_FPS_FILTER)+= vf_fps.o
> Index: allfilters.c
> ===
> --- allfilters.c(revision 4305)
> +++ allfilters.c(working copy)
> @@ -34,6 +34,7 @@
>  return;
>  initialized = 1;
>  
> +REGISTER_FILTER(APPLYFN,applyfn,vf);
>  REGISTER_FILTER(CROP,crop,vf);
>  REGISTER_FILTER(DRAWBOX,drawbox,vf);
>  REGISTER_FILTER(FIFO,fifo,vf);
> Index: vf_applyfn.c
> ===
> --- vf_applyfn.c(revision 0)
> +++ vf_applyfn.c(revision 0)
> @@ -0,0 +1,227 @@
> +/*
> + * applyfn filter
> + * copyright (c) 2009 Zeger Knops
> + *
> + * 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
> + */
> +
> +/**
> + * Assume pow is available
> + * Gamma(g): applyfn=255*pow(Y/255\,g):U:V
> + *
> + * Assume the floor fn is available we can draw cartoons:
> + * applyfn=floor(Y/64)*64:floor(U/64)*64:floor(V/64)*64
> + *
> + * Assume the modulo fn is availabvle we can draw checkerboars
> + * applyfn=(modulo(floor(x/64)\,2)+modulo(floor(y/64)\,2))*Y
> + *
> + * B&W
> + * applyfn=Y:128:128
> + */

Docs and example go to doc/vfilters.texi.

> +#include "libavcodec/eval.h"
> +#include "avfilter.h"
> +#include "libavutil/avstring.h"
> +
> +enum PosOfValue {
> +POV_PI,
> +POV_E,
> +POV_N,
> +POV_W,
> +POV_H,
> +POV_x,
> +POV_y,
> +POV_Y,
> +POV_U,
> +POV_V,
> +POV_A,
> +POV_NULL
> +};

PosOfValue is not a good name, I believe:
enum VarName {
 ...
 VARS_NB
};

is better.

And a PTS var may be useful too.

> +static const char *applyfn_symbols[POV_NULL+1]={
  ^^
Why +1?

> +"PI",
> +"E",
> +"N", ///< frame number (starting at zero)
> +"W", ///< frame width
> +"H", ///< frame height
> +"x", ///< x position of current pixel
> +"y", ///< y position of current pixel
> +"Y", ///< Y value of current pixel
> +"U", ///< U value of current pixel
> +"V", ///< V value of current pixel
> +"A", ///< A value of current pixel
> +NULL
> +};
>
> +typedef struct
> +{
> +AVEvalExpr *value_Y, *value_U, *value_V, *value_A;
> +int hsub, vsub;
> +double values[POV_NULL+1];
> +} ApplyfnContext;
> +
> +static av_cold int init(AVFilterContext *ctx, const char *args, void *opaque)
> +{
> +ApplyfnContext *applyfn = ctx->priv;
> +char Y_expr[256], U_expr[256], V_expr[256], A_expr[256];
> +   const char *error;

Weird indent.

> +   applyfn->values[POV_PI  ] = M_PI;
> +   applyfn->values[POV_E   ] = M_E;
> +   applyfn->values[POV_N   ] = 0.0;
> +   applyfn->values[POV_NULL] = 0.0;
> +
> +   av_strlcpy(Y_expr, "Y", sizeof(Y_expr));
> +av_strlcpy(U_expr, "U", sizeof(U_expr));
> +av_strlcpy(V_expr, "V", sizeof(V_expr));
> +av_strlcpy(A_expr, "A", sizeof(V_expr));
> +
> +   if (args)
> +   sscanf(args, "%255[^:]:%255[^:]:%255[^:]:%255[^:]", Y_expr, 
> U_expr, V_expr, A_expr)

I believe here it would be nice to use av_set_options_string, check
vf_pad.c in the archive for an usage example.

> +
> +   applyfn->value_Y = ff_parse(Y_expr, appl

Re: [FFmpeg-soc] [soc]: r4271 - in libavfilter: doc/vfilters.texi vf_overlay.c

[Stefano Sabatini]

On date Saturday 2009-05-16 19:22:47 +0200, Diego Biurrun encoded:
> On Fri, May 15, 2009 at 11:42:49AM +0200, Benoit Fouet wrote:
> > On 05/15/2009 10:59 AM, Diego Biurrun wrote:
> > > On Fri, May 15, 2009 at 01:16:47AM +0200, stefano wrote:
> > >   
> > >> Patch by Martin Storsjö .
> > >
> > > I have no idea what the email address might be.
> > 
> > would s/name/firstname/g help you ?
> 
> Yes, it would.

Done.
___
FFmpeg-soc mailing list
FFmpeg-soc@mplayerhq.hu
https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc

Re: [FFmpeg-soc] [PATCH] new avfilter vf_logo.c to overlay a (alpha-pathed) logo onto a video stream

[Stefano Sabatini]

On date Sunday 2009-04-26 13:42:04 +0200, Jürgen Meissner encoded:
> vf_logo.c implements avfilters "logo" and "logo_without_alpha"
>
> logo=10:20:logo.jpg overlays the video at x=10 y=20 with the logo (is  
> respecting the alpha-path of the logo)
> logo=-1:1:logo.png   overlays the video at 1 pixel from the right and 1  
> pixel from the top border
> logo_without_alpha=10:20:logo.gif overlays the video at 10,20 for all  
> pixels of the logo, doesn't look for an alpha-path in the logo
> logo=0:0:0:10:20:logo.gif overlays video at 10,20 and assumes black  
> RGB=(0,0,0) is the transparent color in the logo
>
> vf_logo.c is relying on the new pixdesc.c rather than the old pix-fmt.c  
> and therefor needs pixdesc.o to be included into the libavcodec.a 
> archive.
>
> 03_libavcodec_Makefile.diff adds the pixdesc.o to the OBS list in the  
> libavcodec/Makefile
>
> mfG J.Meissner
>
>
>

> Index: allfilters.c
> ===
> --- allfilters.c  (revision 4238)
> +++ allfilters.c  (working copy)
> @@ -40,6 +40,7 @@
>  REGISTER_FILTER(FORMAT,format,vf);
>  REGISTER_FILTER(FPS,fps,vf);
>  REGISTER_FILTER(HFLIP,hflip,vf);
> +REGISTER_FILTER(LOGO,logo,vf);
>  REGISTER_FILTER(NEGATE,negate,vf);
>  REGISTER_FILTER(NOFORMAT,noformat,vf);
>  REGISTER_FILTER(NULL,null,vf);
> Index: diffs/03_libavcodec_Makefile.diff
> ===
> --- diffs/03_libavcodec_Makefile.diff (revision 0)
> +++ diffs/03_libavcodec_Makefile.diff (revision 0)
> @@ -0,0 +1,12 @@
> +Index: libavcodec/Makefile
> +===
> +--- libavcodec/Makefile  (revision 18682)
>  libavcodec/Makefile  (working copy)
> +@@ -18,6 +18,7 @@
> +opt.o\
> +options.o\
> +parser.o \
> ++   pixdesc.o\
> +raw.o\
> +resample.o   \
> +resample2.o  \
> Index: doc/vfilters.texi
> ===
> --- doc/vfilters.texi (revision 4238)
> +++ doc/vfilters.texi (working copy)
> @@ -117,6 +117,47 @@
>  
>  Flip the video horizontally.
>  
> +...@section logo
> +
> +...@example
> +./ffmpeg -i inputvideofile -vfilters logo=10:20:logofile.png -y 
> outputvideofile
> +...@end example
> +
> + image of logofile.png is overlayed onto every frame of inputvideofile 
> + at offset x=10 y=20 giving outputvideofile
> +
> + x 
> +
> +   Defines a logo (left border) offset from the left side of the video.
> +   A negative value offsets (logo right border) from
> +   the right side of the video.
> +
> + y 
> +
> +   Defines a logo (top border) offset from the top of the video.
> +   A negative value offsets (logo bottom border) from
> +   the bottom of the video.
> +
> + if logofile has no alpha-path You can prefix another 3 fields R,G,B
> + to select a RGB-color to be the transparent one
> +
> + 
> + REMARKS: there is a lot of gymnastics with the single logo frame, we do 
> + this to avoid any transformation for ALL the many 
> + video frames

Strange formatting.

> +...@example
> +./ffmpeg -i inputvideofile -vfilters logo=0:0:0:10:20:logofile.png -y 
> outputvideofile
> +...@end example

Maybe you should use a non-positional system, for example that
implemented by the patches I posted on ffmpeg-devel
(av_set_options_set), but wait for this since they still have to be
discussed. Also it should avoid the "_without_alpha" thing.

> +
> + black is the color to be understood as transparent

Maybe this should be configurable.

> +
> +...@example
> +./ffmpeg -i inputvideofile -vfilters logo_without_alpha=10:20:logofile.png 
> -y outputvideofile
> +...@end example
> +
> + force overlaying all pixels (even if no alpha-path)
> +
>  @section negate
>  
>  @example
> Index: vf_logo.c
> ===
> --- vf_logo.c (revision 0)
> +++ vf_logo.c (revision 0)
> @@ -0,0 +1,859 @@
> +#define VF_LOGO_VERSION "0.9.8 26.4.2009"

No need for version.

> +/**
> + * libavfilter/vf_logo.c
> + * filter to overlay (with or without alpha) logo on top of video
> + * Copyright (c) 2009 Juergen Meissner (using parts of previous code)
> + * Copyright (c) 2008 Victor Paesa (libavfilter/vsrc_movie.c)
> + * Copyright (c) 2007 Bobby Bingham(libavfilter/vf_overlay.c)
> + * Copyright (c) 2007 Juergen Meissner (vhook/overlay.c)
> + *
> + * This file is part of FFmpeg.
> + *
> + * FFmpeg is free software; you can redistribute it and/or
> + * modify it under the terms of 

Re: [FFmpeg-soc] [soc]: r4179 - in libavfilter: checkout.sh diffs/01_ffplay_filters.diff diffs/02_ffmpeg_filters.diff

[Stefano Sabatini]

On date Sunday 2009-03-22 19:10:34 +0100, Michael Niedermayer encoded:
> On Sun, Mar 22, 2009 at 09:11:58AM +0100, Stefano Sabatini wrote:
> > On date Sunday 2009-03-22 02:49:12 +0100, Michael Niedermayer encoded:
> > > On Sun, Mar 22, 2009 at 01:08:24AM +0100, Stefano Sabatini wrote:
> > > > On date Sunday 2009-03-22 01:05:42 +0100, stefano encoded:
> > > > > Author: stefano
> > > > > Date: Sun Mar 22 01:05:42 2009
> > > > > New Revision: 4179
> > > > > 
> > > > > Log:
> > > > > Update to FFmpeg r18133.
> > > > > 
> > > > > Modified:
> > > > >libavfilter/checkout.sh
> > > > >libavfilter/diffs/01_ffplay_filters.diff
> > > > >libavfilter/diffs/02_ffmpeg_filters.diff
> > > > 
> > > > This breaks regression for mxf_d10.
> > > > 
> > > > It is expected, since that test uses -padtop, which works differently
> > > > from the one in FFmpeg (also the soc one looks broken).
> > > 
> > > he?!
> > > there should be no -pad* in libavfilter svn because that should be done
> > > by filters.
> > 
> > Do you mean that the various -padXXX options should be removed from
> > ffmpeg.c right now?
> 
> from soc libavfilter ffmpeg yes thats an option
> 
> 
> > 
> > Only problem is that regression test then will fail, so I suggest to
> > wait up to when will have a pad filter.
> 
> id suggest to drop all pad options from the regression tests

So the question is why the mxf_d10 test uses -padtop in the first
place.

Regards.
___
FFmpeg-soc mailing list
FFmpeg-soc@mplayerhq.hu
https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc

Re: [FFmpeg-soc] [soc]: r4179 - in libavfilter: checkout.sh diffs/01_ffplay_filters.diff diffs/02_ffmpeg_filters.diff

[Stefano Sabatini]

On date Sunday 2009-03-22 02:49:12 +0100, Michael Niedermayer encoded:
> On Sun, Mar 22, 2009 at 01:08:24AM +0100, Stefano Sabatini wrote:
> > On date Sunday 2009-03-22 01:05:42 +0100, stefano encoded:
> > > Author: stefano
> > > Date: Sun Mar 22 01:05:42 2009
> > > New Revision: 4179
> > > 
> > > Log:
> > > Update to FFmpeg r18133.
> > > 
> > > Modified:
> > >libavfilter/checkout.sh
> > >libavfilter/diffs/01_ffplay_filters.diff
> > >libavfilter/diffs/02_ffmpeg_filters.diff
> > 
> > This breaks regression for mxf_d10.
> > 
> > It is expected, since that test uses -padtop, which works differently
> > from the one in FFmpeg (also the soc one looks broken).
> 
> he?!
> there should be no -pad* in libavfilter svn because that should be done
> by filters.

Do you mean that the various -padXXX options should be removed from
ffmpeg.c right now?

Only problem is that regression test then will fail, so I suggest to
wait up to when will have a pad filter.

Regards.
___
FFmpeg-soc mailing list
FFmpeg-soc@mplayerhq.hu
https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc

Re: [FFmpeg-soc] [soc]: r4179 - in libavfilter: checkout.sh diffs/01_ffplay_filters.diff diffs/02_ffmpeg_filters.diff

[Stefano Sabatini]

On date Sunday 2009-03-22 01:05:42 +0100, stefano encoded:
> Author: stefano
> Date: Sun Mar 22 01:05:42 2009
> New Revision: 4179
> 
> Log:
> Update to FFmpeg r18133.
> 
> Modified:
>libavfilter/checkout.sh
>libavfilter/diffs/01_ffplay_filters.diff
>libavfilter/diffs/02_ffmpeg_filters.diff

This breaks regression for mxf_d10.

It is expected, since that test uses -padtop, which works differently
from the one in FFmpeg (also the soc one looks broken).

Regards.
___
FFmpeg-soc mailing list
FFmpeg-soc@mplayerhq.hu
https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc

Re: [FFmpeg-soc] FFmpeg Release 0.5 is announced and already in ffmpeg/branches/0.5. hurry up for checking in soc/libavfilter!

[Stefano Sabatini]

On date Tuesday 2009-03-10 19:17:32 +0100, Jürgen Meissner encoded:
> Currently there's not too much in ffmpeg/libavfilter, 
> soc/livabfilter/checkout.sh does include much usefull stuff.
> I appreciated very much, if this could be in the FFmpeg 0.5 Release.
> 
> mfG J.Meissner

Lavfi is still not ready for a full inclusion in SVN, and it won't be
included for sure in the 0.5 branch.

Hopefully, and with more people working on it, it will be included in
the next release.

If you want to know the current state of lavfi and/or want to
contribute to it read the thread: "lavfi state of affairs 2" in the
ffmpeg-devel ML.

Regards.
___
FFmpeg-soc mailing list
FFmpeg-soc@mplayerhq.hu
https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc

Re: [FFmpeg-soc] libavfilter - filter for .ass subtitle rendering using libass

[Stefano Sabatini]

On date Thursday 2009-02-26 10:56:49 +0300, Alexey Lebedeff encoded:
> 
> On Thu, 26 Feb 2009 00:45:04 +0100, Stefano Sabatini wrote:
> > On date Tuesday 2009-02-24 20:28:53 +0300, Alexey Lebedeff encoded:
> >> On Tue, 24 Feb 2009 13:54:08 +0300, Alexey Lebedeff wrote:
> 
> >>   int vsub,hsub;   //< chroma subsampling
> >
> > missing space after the comma
> 
> And the same in the vf_drawbox.c =)

Fixed.
 
> >> } AssContext;
> >> 
> >> static int parse_args(AVFilterContext *ctx, AssContext *context, const 
> >> char* args);
> >> static av_cold int init(AVFilterContext *ctx, const char *args, void 
> >> *opaque)
> >> {
> >>   AssContext *context= ctx->priv;
> >> 
> >>   /* defaults */
> >>   context->margin = 10;
> >>   context->encoding = "utf-8";
> >> 
> >>   if ( parse_args(ctx, context, args) )
> >
> > if (parse_args(...))
> >
> > style is preferred.
> >
> >> return 1;
> >
> > The documentation only says to return 0 in case of success, but all
> > the current filters return a negative value in case of failure, which
> > is consistent with the FFmpeg API, so I'd say to return -1 here and in
> > all the other cases.
> >
> > Also I find quite confusing to parse the args in a distinct function,
> > but maybe it's only me.
> 
> It was too big, and initially I wanted to place libass initialization
> in init() too. But together they was so large, that I decided to split
> them in such way.
> 
> >>   return 0;
> >> }
> 
> >> static int config_input(AVFilterLink *link)
> >> {
> >>   AssContext *context = link->dst->priv;
> >> 
> >>   context->frame_width = link->w;
> >>   context->frame_height = link->h;
> >> 
> >>   context->ass_library = ass_library_init();
> >> 
> >>   if ( !context->ass_library ) {
> >> av_log(0, AV_LOG_ERROR, "ass_library_init() failed!\n");
> >> return 1;
> >>   }
> >> 
> >>   ass_set_fonts_dir(context->ass_library, "");
> >>   ass_set_extract_fonts(context->ass_library, 1);
> >>   ass_set_style_overrides(context->ass_library, NULL);
> >> 
> >>   context->ass_renderer = ass_renderer_init(context->ass_library);
> >>   if ( ! context->ass_renderer ) {
> >> av_log(0, AV_LOG_ERROR, "ass_renderer_init() failed!\n");
> >> return 1;
> >>   }
> >> 
> >>   ass_set_frame_size(context->ass_renderer, link->w, link->h);
> >>   ass_set_margins(context->ass_renderer, context->margin, context->margin, 
> >> context->margin, context->margin);
> >>   ass_set_use_margins(context->ass_renderer, 1);
> >>   ass_set_font_scale(context->ass_renderer, 1.);
> >>   ass_set_fonts(context->ass_renderer, NULL, "Sans");
> >> 
> >>   context->ass_track = ass_read_file(context->ass_library, 
> >> context->filename, context->encoding);
> >>   if ( !context->ass_track ) {
> >> av_log(0, AV_LOG_ERROR, "Failed to read subtitle file with 
> >> ass_read_file()!\n");
> >> return 1;
> >>   }
> >
> > I don't see why this is done here rather than in init().
> Because of link->w and link->h.
> It needs to be checked whether ass_set_frame_size() can be called
> anytime, or libass init sequence is fixed.

This is only used in:
ass_set_frame_size(context->ass_renderer, link->w, link->h);

all the other initialization may be done in init.
Also I think you're missing error check for the various ass*
functions.

But again, if you can work to a libavcodec ASS codec it would be
*much* better, and you have more chance to get included in FFmpeg (and
it will be rather useful by its own).

Check the ffmpeg-devel archive, recently there has been a discussion
on the new subtitles framework.

> > Also av_log should always have a context.
> I was not sure  what to use here, and 0 as context worked fine.
> Will be the 'link->dst' the right parameter for av_log() here?
> 
> >>   avcodec_get_chroma_sub_sample(link->format,
> >>&context->hsub, &context->vsub);
> >> 
> >>   return 0;
> >> }
> >> 
> >> static void start_frame(AVFilterLink *link, AVFilterPicRef *picref)
> >> {
> >>   avfilter_start_frame(link->dst->outputs[0],

Re: [FFmpeg-soc] libavfilter - filter for .ass subtitle rendering using libass

[Stefano Sabatini]

On date Tuesday 2009-02-24 20:28:53 +0300, Alexey Lebedeff encoded:
> On Tue, 24 Feb 2009 13:54:08 +0300, Alexey Lebedeff wrote:
> 
>  AL> If there is any interest in it, I'll do some cleanup to code,
>  AL> properly integrate it into build process, and share the results.
> 
> Here is the very primitive patch to libavfilter Makefile, and source
> of filter itself. No proper build process integration yet.
> 

Content-Description: Makefile patch
> --- Makefile.orig 2009-02-23 10:41:03.0 +
> +++ Makefile  2009-02-24 16:57:36.0 +
> @@ -13,6 +13,7 @@
> graphparser.o \
>  
>  
> +OBJS-$(CONFIG_ASS_FILTER)   += vf_ass.o
>  OBJS-$(CONFIG_CROP_FILTER)   += vf_crop.o
>  OBJS-$(CONFIG_DRAWBOX_FILTER)+= vf_drawbox.o
>  OBJS-$(CONFIG_FPS_FILTER)+= vf_fps.o
> @@ -34,4 +35,8 @@
>  
>  HEADERS = avfilter.h
>  
> +CFLAGS += -I/usr/include/ass
> +EXTRALIBS += -lass
> +
>  include $(SUBDIR)../subdir.mak
> +
> --- allfilters.c.orig 2009-02-23 10:41:03.0 +
> +++ allfilters.c  2009-02-23 11:26:18.0 +
> @@ -34,6 +34,7 @@
>  return;
>  initialized = 1;
>  
> +REGISTER_FILTER(ASS,ass,vf);
>  REGISTER_FILTER(CROP,crop,vf);
>  REGISTER_FILTER(DRAWBOX,drawbox,vf);
>  REGISTER_FILTER(FIFO,fifo,vf);

Content-Description: ass filter
> /*
>  * SSA/ASS subtitles rendering filter, using libssa.
>  * Based on vf_drawbox.c from libavfilter and vf_ass.c from mplayer.
>  *
>  * Copyright (c) 2006 Evgeniy Stepanov 
>  * Copyright (c) 2008 Affine Systems, Inc (Michael Sullivan, Bobby Impollonia)
>  * Copyright (c) 2009 Alexey Lebedeff 
>  *
>  * This program 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.
> 
>  * This program 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 this program; if not, write to the Free Software
>  * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston,
>  * MA 02110-1301, USA.
>  */
> 
> /*
>  * Usage: '-vfilters ass=filename:somefile.ass|margin:50|encoding:utf-8'
>  * Only 'filename' param is mandatory.
>  */
> 
> #include 
> #include 
> #include 
> 
> #include 
> 
> #include "avfilter.h"
> 
> typedef struct
> {
>   ass_library_t *ass_library;
>   ass_renderer_t *ass_renderer;
>   ass_track_t *ass_track;
> 
>   int margin;
>   char *filename;
>   char *encoding;
> 
>   int frame_width, frame_height;
>   int vsub,hsub;   //< chroma subsampling

missing space after the comma

> } AssContext;
> 
> static int parse_args(AVFilterContext *ctx, AssContext *context, const char* 
> args);
> static av_cold int init(AVFilterContext *ctx, const char *args, void *opaque)
> {
>   AssContext *context= ctx->priv;
> 
>   /* defaults */
>   context->margin = 10;
>   context->encoding = "utf-8";
> 
>   if ( parse_args(ctx, context, args) )

if (parse_args(...))

style is preferred.

> return 1;

The documentation only says to return 0 in case of success, but all
the current filters return a negative value in case of failure, which
is consistent with the FFmpeg API, so I'd say to return -1 here and in
all the other cases.

Also I find quite confusing to parse the args in a distinct function,
but maybe it's only me.

>   return 0;
> }
> 
> static int query_formats(AVFilterContext *ctx)
> {
>   avfilter_set_common_formats
> (ctx,
>  avfilter_make_format_list(10,
>  PIX_FMT_YUV444P,  PIX_FMT_YUV422P,  
> PIX_FMT_YUV420P,
>  PIX_FMT_YUV411P,  PIX_FMT_YUV410P,
>  PIX_FMT_YUVJ444P, PIX_FMT_YUVJ422P, 
> PIX_FMT_YUVJ420P,
>  PIX_FMT_YUV440P,  PIX_FMT_YUVJ440P));
>   return 0;
> }

Weird indent, please follows K&R style, no tabs and four spaces
indent.

> static int config_input(AVFilterLink *link)
> {
>   AssContext *context = link->dst->priv;
> 
>   context->frame_width = link->w;
>   context->frame_height = link->h;
> 
>   context->ass_library = ass_library_init();
> 
>   if ( !context->ass_library ) {
> av_log(0, AV_LOG_ERROR, "ass_library_init() failed!\n");
> return 1;
>   }
> 
>   ass_set_fonts_dir(context->ass_library, "");
>   ass_set_extract_fonts(context->ass_library, 1);
>   ass_set_style_overrides(context->ass_library, NULL);
> 
>   context->ass_renderer = ass_renderer_init(context->ass_library);
>   if ( ! context->ass_renderer ) {
> av_log(0, AV_LOG_ERROR, "ass_renderer_init() failed!\n");
> return 1;
>   }
> 
>   ass_set_frame_size(context->ass_renderer, link->w, link->h);
>   ass_set_margins(context->ass_renderer,