Lines Matching refs:flush
226 while in the Executing state using {@link #flush}.
374 specific data may be lost during the flush. You must resubmit the data using buffers marked with
375 {@link #BUFFER_FLAG_CODEC_CONFIG} after such flush to ensure proper codec operation.
442 #flush} to transition the codec to the Running sub-state and start receiving input buffers.
669 It is important that the input data after {@link #start} or {@link #flush} starts at a suitable
708 seek) you <strong>MUST</strong> flush the decoder. Since all output buffers are immediately
709 revoked at the point of the flush, you may want to first signal then wait for the end-of-stream
710 before you call {@code flush}. It is important that the input data after a flush starts at a
713 <strong>Note:</strong> the format of the data submitted after a flush must not change; {@link
714 #flush} does not support format discontinuities; for that, a full {@link #stop} - {@link
718 <strong>Also note:</strong> if you flush the codec too soon after {@link #start} –
726 seek) it is <em>not necessary</em> to flush the decoder; however, input data after the
740 {@link #flush} shortly after you have changed the picture size. If you have not received
993 <td class=fn>{@link #flush flush}</td>
1568 * after this, unless of course, {@link #flush} follows.
2037 * or just after {@link #flush} for a codec that is configured
2085 * after {@code flush} has returned to resume codec operations. The codec
2088 * callbacks that were not handled prior to calling {@code flush}.
2089 * The indices returned via these callbacks also become invalid upon calling {@code flush} and
2099 public final void flush() {
2285 * {@link #flush} by specifying the flag {@link
3263 * Also, {@link #flush} behaves differently in asynchronous mode. After calling
3264 * {@code flush}, you must call {@link #start} to "resume" receiving input buffers,