On Wed, 31 Oct 2018, Derek Buitenhuis wrote:
On 30/10/2018 19:49, Martin Storsjö wrote:
Hmm, that might make sense, but with a little twist. The max reordered
frames for H.264 is known, but onto that you also get more delay due to
frame threads and other details that this function within x264 knows
about. So that would make it [H264 max reordering] + [threads] +
[constant] or something such?
Looking at the source, it's more complicated than that, with e.g.:
h->frames.i_delay = X264_MAX( h->frames.i_delay, h->param.rc.i_lookahead );
I think you're better off not trying to duplicate this logic.
Indeed, I don't want to duplicate that.
Even though we do allow reconfiguration, it doesn't look like we support
changing any parameters which would actually affect the delay, only RC
method and targets (CRF, bitrate, etc). So given that, the current patch
probably should be safe - what do you think? Or the current patch, with an
added margin of 16 on top just in case?
// Martin
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
