On Sun, 26 Nov 2017, James Almer wrote:

On 11/26/2017 12:19 PM, Nicolas George wrote:
James Almer (2017-11-26):
The old decode API is not scheduled for removal right now probably
because 99% of decoders need to be ported.

I think this statement contains some confusion that is harmful to the

There are two interfaces worth considering in this discussion: the
application -> library interface, i.e. the avcodec_decode_*dio()
functions, and the framework -> decoder interface, i.e. the decode /
receive_frame / ... callbacks.

When you are stating "because 99% of decoders need to be ported", you
are referring to the framework-decoder interface. On the other hand, the
misuse of the API that is at the origin of this thread is related to the
application-library interface.

Yes, my bad. Got the public API and the internal callbacks mixed. So
ignore that part.
Guess then that the functions did not get a removal schedule because
they are still too ubiquitous downstream.

My second paragraph stands, in any case. I consider this a good chance
to get downstreams to migrate.

Okay, I am exagarating a bit, but unconditionally returning AVERROR(ENOSYS) would be an even better incentive, no? :)

We can blame API usage (we should rather blame unclear documentation), but no matter how we put it, with the change, we broke the user experience of two major projects. If fixing it (at least partially) is so easy, I still don't see why we should not do that.

People who still oppose this change, please respond.

ffmpeg-devel mailing list

Reply via email to