Re: [FFmpeg-devel] [PATCH 18/24] fftools/ffmpeg: add thread-aware transcode scheduling infrastructure

[Anton Khirnov <anton@khirnov.net>]

Quoting James Almer (2023-11-04 14:53:25)
> On 11/4/2023 4:56 AM, Anton Khirnov wrote:
> > +static void *task_wrapper(void *arg)
> > +{
> > +    SchTask  *task = arg;
> > +    Scheduler *sch = task->parent;
> > +    int ret;
> > +    int err = 0;
> > +
> > +    ret = (intptr_t)task->func(task->func_arg);
> > +    if (ret < 0)
> > +        av_log(task->func_arg, AV_LOG_ERROR,
> > +               "Task finished with error code: %d (%s)\n", ret, av_err2str(ret));
> > +
> > +    switch (task->node.type) {
> > +    case SCH_NODE_TYPE_DEMUX:       err = demux_done (sch, task->node.idx); break;
> > +    case SCH_NODE_TYPE_MUX:         err = mux_done   (sch, task->node.idx); break;
> > +    case SCH_NODE_TYPE_DEC:         err = dec_done   (sch, task->node.idx); break;
> > +    case SCH_NODE_TYPE_ENC:         err = enc_done   (sch, task->node.idx); break;
> > +    case SCH_NODE_TYPE_FILTER_IN:   err = filter_done(sch, task->node.idx); break;
> 
> task->node.type seems to be constant, so wouldn't it be faster,

This is only called once per node, so I don't think performance
considerations make sense.

> or at least cleaner looking here, to use a function pointer assigned
> in task_init()?

That just moves the switch to a different place, adds an extra function
pointer, and makes it less clear what is being called, so I don't see
how it's an improvement.

That said, I do have some vague thoughts about abstracting away some
node-type specific things, but I'd rather leave that for later.

-- 
Anton Khirnov
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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