On Wed, 14 Dec 2016 14:23:05 +0000 Matteo Naccari <matteo.nacc...@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? _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
