On 4/10/2020 11:07 AM, Derek Buitenhuis wrote: > On 10/04/2020 00:09, James Almer wrote: >> EAGAIN is returned when input is provided but can't be consumed. The >> filtering >> process is unaffected in this case, and the function will be able to consume >> new input after retrieving filtered packets with av_bsf_receive_packet(). >> >> Remove the line about empty packets never failing added in >> 41b05b849f215b03eeb9e3608571ba47de64182a while at it. Even if it's currently >> the case, it unnecessarily constrains the API and could be changed in the >> future >> in case it needs to be extended. >> The user should always check for errors and never expect a call to never >> fail. >> >> Signed-off-by: James Almer <jamr...@gmail.com> >> --- >> libavcodec/avcodec.h | 5 +++-- >> 1 file changed, 3 insertions(+), 2 deletions(-) > > Sounds good to me. > > - Derek
Will push, thanks. That aside, I'm planning on restructuring these bsf functions internally, making it behave more in line with the send_packet/receive_frame API for decoding, and there are two options for this: One, i keep the behavior described in the doxy after this patch regarding return values from av_bsf_send_packet() (every AVERROR code except EAGAIN being an error). Or two, make it return EOF instead of 0 when extra unnecessary flush packets are passed to it, thus making both bsf and decode APIs behave exactly the same. The latter would be ideal, but i don't know if it could be considered an API change or not. It would have no effect on existing usage for example in decode.c and the CLI. The latter in fact considers EOF from av_bsf_send_packet() a possibility, so it may have been an oversight back when the bsf API was first written. What do you think? _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
