+ // if we're re-ordering frames, check if this frame is too large to reorder
+ if ( pv->init_delay && in->stop - in->start > pv->init_delay )
+ {
+ // This frame's duration is larger than the time allotted for b-frame
+ // reordering. That means that if it's used as a reference the decoder
+ // won't be able to move it early enough to render it in correct
+ // sequence & the playback will have odd jumps & twitches. To make
+ // sure this doesn't happen we pretend this frame is multiple
+ // frames, each with duration <= init_delay. Since each of these
+ // new frames contains the same image the visual effect is identical
+ // to the original but the resulting stream can now be coded without
+ // error. We take advantage of the fact that x264 buffers frame
+ // data internally to feed the same image into the encoder multiple
+ // times, just changing its start & stop times each time.
+ int64_t orig_stop = in->stop;
+ int64_t new_stop = in->start;
+ hb_buffer_t *last_buf = NULL;
+
+ // We want to spread the new frames uniformly over the total time
+ // so that we don't end up with a very short frame at the end.
+ // In the number of pieces calculation we add in init_delay-1 to
+ // round up but not add an extra piece if the frame duration is
+ // a multiple of init_delay. The final increment of frame_dur is
+ // to restore the bits that got truncated by the divide on the
+ // previous line. If we don't do this we end up with an extra tiny
+ // frame at the end whose duration is npieces-1.
+ int64_t frame_dur = orig_stop - new_stop;
+ int64_t npieces = ( frame_dur + pv->init_delay - 1 ) / pv->init_delay;
+ frame_dur /= npieces;
+ ++frame_dur;
+
+ while ( in->start < orig_stop )
+ {
+ new_stop += frame_dur;
+ if ( new_stop > orig_stop )
+ new_stop = orig_stop;
+ in->stop = new_stop;
+ hb_buffer_t *buf = x264_encode( w, in );
+ if ( buf )
+ {
+ if ( last_buf == NULL )
+ *buf_out = buf;
+ else
+ last_buf->next = buf;
+ last_buf = buf;