[FFmpeg-devel] [PATCH v3] Added Turing codec interface for ffmpeg

[wm4]

On Wed, 14 Dec 2016 14:23:05 +0000
Matteo Naccari <Matteo.Naccari at bbc.co.uk> wrote:

> > Missing error handling, and maybe overflow handling. Also, we don't use
> > malloc/realloc/free, but av_malloc/av_realloc/av_free. I'm not sure why we
> > do this (it doesn't have much of a justification for realloc at least), but it's
> > probably better to be consistent.  
> 
> Ok, point taken on the av_* functions. On the handling bit, I was thinking to flag the error via av_log and then call exit_program(1), after, of course, having released the memory allocated up to that point. Would that be ok?

Of course this would be not ok. We never flag errors via av_log (how
would this even work). We also don't call exit() in the libraries, if
you mean this. Or maybe you're talking about ffmpeg.c - no, ffmpeg.c is
not the only API user, and of course not all API users should be
updated to do some weird h264_turing codec error handling.

You do what all other codecs in libavcodec also do: return an error
code to the caller, and maybe log an error message (not in obscure OOM
cases, probably).

> >
> > Does the "s" field have any purpose? It seems to be redundant with the
> > other fields.  
> 
> It has. It points to the position in the options buffer which is going to be filled with the command line being parsed. So it's not redundant.

Then what does buffer_filled do?