So I kinda shelved this issue as I had others to resolve, but since then I've fixed all but 2 of my issues, this being one of them.
I worry less about dropping frames when ending a recording, however it is fairly obtrusive in both the console and the resulting file to drop / duplicate 100 frames from the get go. As far as I can tell this is happening solely because max rtbufsize is limited by it's INT32 container, if the buffer was larger rather than dropping frames at the beginning I'd theoretically just be transcoding under real time for a few seconds while the GPU catches up. Looking at the source code I can see the rtbufsize option inside the "option_table.h" file: [image: image.png] It seems that a single variable, "AV_OPT_TYPE_INT", is being passed to many of the options including this one, but there is also an "AV_OPT_TYPE_INT64" being passed to others in proximity. Would fixing the issue be as simple as passing rtbufsize AV_OPT_TYPE_INT64 instead of AV_OPT_TYPE_INT? Apologies if this isn't the best place to ask about this, I'm not the most experienced when it comes to working with code, and I definitely don't understand the process of proposing such a change for official builds. In the end, I think users could benefit from rtbufsize being stored in a larger container. >
_______________________________________________ ffmpeg-user mailing list [email protected] http://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email [email protected] with subject "unsubscribe".
