[FFmpeg-devel] [PATCH] [2/??] [3/3] Filter graphs - Parser for a graph description

[Michael Niedermayer]

On Wed, May 07, 2008 at 08:04:13PM +0200, Vitor Sessak wrote:
> Michael Niedermayer wrote:
> > On Mon, May 05, 2008 at 10:01:36PM +0200, Vitor Sessak wrote:
> >> Michael Niedermayer wrote:
> >>> On Wed, Apr 23, 2008 at 11:05:37PM +0200, Vitor Sessak wrote:
> >>>> Hi and thanks for the review
> >>> [...]
> >>>>>>             p->filter = filter;
> >>>>>>             p->pad_idx = pad;
> >>>>>>             p->next = *openLinks;
> >>>>>>             *openLinks = p;
> >>>>>>         }
> >>>>>>     }
> >>>>>>
> >>>>>>
> >>>>>>     if(*currInputs) {
> >>>>>>         av_log(log_ctx, AV_LOG_ERROR,
> >>>>>>                "Too many inputs specified for the \"%s\" filter.\n",
> >>>>>>                filter->name);
> >>>>>>         return -1;
> >>>>>>     }
> >>>>>>
> >>>>>>     pad = filter->output_count;
> >>>>>>     while(pad) {
> >>>>>>         AVFilterInOut *currlinkn = av_malloc(sizeof(AVFilterInOut));
> >>>>>>         pad--;
> >>>>>>         currlinkn->name    = NULL;
> >>>>>>         currlinkn->type    = LinkTypeOut;
> >>>>>>         currlinkn->filter  = filter;
> >>>>>>         currlinkn->pad_idx = pad;
> >>>>>>         currlinkn->next    = *currInputs;
> >>>>>>         *currInputs = currlinkn;
> >>>>> somehow i thik this can be factored with the above as well
> >>>> Maybe, but without worsening a lot readability?
> >>> We need to find a way to simplify the whole parser without reducing
> >>> readability.
> >>> Its much more complex than i would like ...
> >> Do you really think it can be so much more simpler? The "complex" part
> >> of it (free_inout(), extract_inout(), link_filter_inouts(),
> >> parse_inputs(), parse_outputs(), avfilter_parse_graph()) make 240 lines
> >> of code.
> > 
> > What i really dont like on the code is that it is complex and at the
> > same time only supports a small subset of what we wanted to support.
> > 300 lines would be fine for a complete implemantation with ; * () user
> > defined filters, and all the other things discussed
> > Saying ok to the code to then see it grow to 3 times that to support
> > everything is something i really dont want to see ...
> 
> Maybe a way to simplify it would be to use nop filters in the following
> way: to parse "filter1 [T1], filter2" do

uhm, i do not like this idea ...

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Asymptotically faster algorithms should always be preferred if you have
asymptotical amounts of data
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20080507/5b58c4b0/attachment.pgp>