Le nonidi 9 nivôse, an CCXXV, Michael Niedermayer a écrit : > avfilter_process_command() has a return code, should this be checked > or passed on somehow ?
Currently, the return code of avfilter_process_command() is ignored here. Since this is a refactoring commit, I do not want to introduce functional changes in it. I added a return code to ff_inlink_process_commands() for future convenience, but for now it is always 0 and ignored by the caller. Using the return codes can be added later; I expect the number of call sites will stay very small for a long time. Actually, I am not even sure what to do with the return code. Discard the corresponding frame? Fail immediately? Print a warning? Queue the return code in the link? The semantic has not been well defined, and it is quite orthogonal to the changes I am working on. > gut feeling but, if the only thing from the frame that is used is the > pts, it may be more flexible to pass the pts instead of the frame. I wanted to keep the symmetry with ff_inlink_process_timeline(), and that one already uses another field of the frame as a variable for the expression, and could use more. As long as the functions are ff_* instead of av_* and there are only a few call sites, changing one way or the other is very easy, so I propose to leave it that way for now. Regards, -- Nicolas George
signature.asc
Description: Digital signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
