Hello Deron, > > Either way, why would the default behavior ever be to drop even a single > frame unless specifically aborted by the user? Seems sloppy, and when half > second fades at the end are dropped it makes the video ending abrupt. The > current driver would be useful only in a scenario where ffmpeg was used to > generate a final HD-SDI video stream. The tool is much more capable than that.
I think part of this issue is a side-effect of the way the libavformat/libavdevice API is designed. The API has a calls for write_header(), write_packet(), and write_trailer(). There is the ability to explicitly flush out any pending buffers, but the API doesn’t have an explicit way to close down the output and throw away any pending video frames. There are numerous cases where you would want to exit immediately without putting out pending video buffers (such as a realtime decoder where you don’t want to push out another 1 second of video). The ffmpeg command line tool basically treats SIGTERM and SIGINT in the same manner - they empty out their mux queue and call write_trailer(), which today in the case of the decklink module results in it terminating immediately without flushing any pending buffers. One approach that could be taken would be to change the ffmpeg program to explicitly call a flush before calling write_trailer() when receiving SIGTERM or at the end of input. This would result in all video frames being put out and then write_trailer() would continue to stop output immediately on receipt. In the SIGINT case though, it would call write_trailer() without flushing pending buffers, which I suspect more closely matches a user’s expectations (“I said interrupt the process immediately”). This is a more invasive change though since changing the ffmpeg program impacts all other inputs and outputs. Also, flush commands can be received at other points, and blocking while output gets flushed could cause stalling in the pipeline (which is really bad when reading from a realtime input source). The whole pre-roll logic in the decklink output needs more work in general. There’s also a bug where we track the last_pts, but we don’t distinguish between PTS values coming from video versus audio (which are clocked at different rates), and thus the Stop call we sometimes hang. I’ve cleaned up a good bit of those sorts of issues in a private tree but haven’t submitted the patches upstream yet. In general I agree with the sentiment that the use case you’re describing should be handled - it’s largely just a question of how we do that within the constraints of a relatively inflexible API without breaking anything else. Devin --- Devin Heitmueller - LTN Global Communications dheitmuel...@ltnglobal.com _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
