On 4/17/2020 6:11 PM, James Almer wrote: > On 4/17/2020 5:40 PM, Andreas Rheinhardt wrote: >> James Almer: >>> On 4/17/2020 3:49 PM, Andreas Rheinhardt wrote: >>>> What is the caller now supposed to do with the packet he has? Submit it >>>> again for filtering? >>> >>> In case of failure, you should abort the process or flush and attempt to >>> resume filtering in a fresh state. Trying to send more data after you >>> got an invalid data error is not going to get good results. >>> >> If one sends data different from the data that led to the invalid data >> error one might very well get good results. That is what is being done >> for ages in ffmpeg.c as well as mux.c and probably a few other places. >> That's also why it is so important to know whether it was the data that >> one just sent that caused the error or not. >> >> Your advice is btw against the current documentation (the part which you >> want to remove, but not because of the error handling) > > True that the CLI does not abort on error by default. But I'm not sure > what part of my doxy change is against the above advice. I only > documented the fact av_bsf_send_packet() returning EAGAIN must not be > considered an error.
Nevermind, i realize now you were talking about the doxy change in this patch. Sorry about that. I removed it because it of course would no longer be required to call av_bsf_receive_packet() until the filter is drained after a change like this, when you could feed new packets as they are filtered. It would still be possible, but no longer the only option. _______________________________________________ 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".
