On Mon, Mar 06, 2017 at 11:34:20AM +0100, wm4 wrote:
> --- a/libavcodec/avcodec.h
> +++ b/libavcodec/avcodec.h
> @@ -161,7 +168,22 @@
>   * and will result in arbitrary behavior.
>   *
>   * Some codecs might require using the new API; using the old API will return
> - * an error when calling it.
> + * an error when calling it. All codecs support the new API.
> + *
> + * A codec is not allowed to return EAGAIN for both sending and receiving. 
> This
> + * would be an invalid state, which could put the codec user into an endless
> + * loop. The API has no concept of time either: it cannot happen that trying 
> to
> + * do avcodec_send_packet() results in EAGAIN, but a repeated call 1 second
> + * later accepts the packet (with no other receive/flush API calls involved).
> + * The API is a strict state machine, and the passage of time is not supposed
> + * to influence it. Some timing-dependent behavior might still be deemed
> + * acceptable in certain cases. But it must never result in both send/receive
> + * returning EAGAIN at the same time at any point. It must also absolutely be
> + * avoided that the current state is "unstable" and can "flip flopping" 
> between

"flip-flop"

> + * the send/receive APIs allowing progress. For example, it's not allowed 
> that
> + * the codec randomly decides that it actually wants to consume a packet now
> + * instead of returning a frame, after it just returned EAGAIN on an
> + * avcodec_send_packet() call.

The paragraph reads much better now.

Diego
_______________________________________________
libav-devel mailing list
[email protected]
https://lists.libav.org/mailman/listinfo/libav-devel

Reply via email to