[FFmpeg-devel] [RFC] The meaning of AVERROR_NOTSUPP

Stefano Sabatini stefano.sabatini-lala
Sat Apr 3 13:31:29 CEST 2010


On date Saturday 2010-04-03 12:36:01 +0200, Michael Niedermayer encoded:
> On Fri, Apr 02, 2010 at 03:33:55PM +0200, Stefano Sabatini wrote:
> > On date Saturday 2010-03-27 00:51:13 +0100, Stefano Sabatini encoded:
> > > On date Tuesday 2010-03-23 00:57:17 +0100, Stefano Sabatini encoded:
> > > > On date Monday 2010-03-22 10:27:03 +0100, Michael Niedermayer encoded:
> > > > > On Sun, Mar 21, 2010 at 10:51:12PM +0100, Stefano Sabatini wrote:
> > > > > > On date Sunday 2010-03-21 22:38:28 +0100, Michael Niedermayer encoded:
> > > [...]
> > > > > AVERROR_NOTSUPP feels more toward a feature that can be supported but is not
> > > > > we also might want to have a 
> > > > > AVERROR_DISABLED for a feature suported but not compiled in
> > > > > but then there is AVERROR_PATCHWELCOME and iam not sure what AVERROR_NOTSUPP is
> > > > > supposed to mean then
> > > > > anyway, error docs are poor and you are changing error code without their
> > > > > meaning being clearly documented.
> > > > 
> > > > Description for AVERROR_NOTSUPP:
> > > > #define AVERROR_NOTSUPP     AVERROR(ENOSYS)  /**< Operation not supported. */
> > > > 
> > > > Description for AVERROR_PATCHWELCOME:
> > > > #define AVERROR_PATCHWELCOME    (-MKTAG('P','A','W','E')) /**< Not yet implemented in FFmpeg. Patches welcome. */
> > > > 
> > > > My interpretation of AVERROR_NOTSUPP:
> > > > The *operation* requested is not legal/valid, as it is not supported
> > > > by the element being requested.
> > > > 
> > > > So AVERROR_NOTSUPP should be returned just in case a certain operation
> > > > is requested to an object for which that operation doesn't make sense
> > > > / cannot be implemented, and in this sense is semantically near to the
> > > > meaning of ENOSYS.
> > > > 
> > > > Think for example of a seek operation in a pipe, for which
> > > > AVERROR_PATCHWELCOME wouldn't make sense.
> > > > 
> > > > I recognize though that the term "supported" in the "not supported"
> > > > expression may lead to confusion, as it suggests what you said, so I'd
> > > > suggest to use instead AVERROR_ILLEGALOPERATION or
> > > > AVERROR_INVALIDOPERATION.
> > > > 
> > > > As for the distinction between AVERROR_DISABLED and
> > > > AVERROR_PATCHWELCOME, I don't think that would be a good idea
> > > > implementation-wise, as most of the time a program can't tell the
> > > > distinction amongst the two.
> > > > 
> > > > For example av_error_input_format() doesn't know if it can't recognize
> > > > a format because it has not been compiled in, because the format is
> > > > not implemented, or because we inflicted to him bogus random data.
> > > > 
> > > > If you agree with the semantics I proposed, I'll post a patch for
> > > > clarifying the description of AVERROR_NOTSUPP, also tell me what do
> > > > you think about the AVERROR_INVALIDOPERATION rename.
> > > 
> > > Currently we have just one use of AVERROR_NOTSUPP:
> > > 
> > > in libavformat/file.c:
> > > static int64_t file_seek(URLContext *h, int64_t pos, int whence)
> > > {
> > >     int fd = (intptr_t) h->priv_data;
> > >     if (whence != SEEK_SET && whence != SEEK_CUR && whence != SEEK_END)
> > >         return AVERROR_NOTSUPP;
> > >     return lseek(fd, pos, whence);
> > > }
> > > 
> > > This suggests the interpretation of AVERROR_NOTSUPP as "Operation
> > > non-valid or illegal".
> > > 
> > > Currently AVERROR_NOTSUPP is defined as AVERROR(ENOSYS), definition from [1]:
> > > |[ENOSYS]
> > > | Function not implemented. An attempt was made to use a function that
> > > | is not available in this implementation.
> > > 
> > > Then we have the description of ENOTSUP, lexically close to AVERROR_NOTSUPP:
> > > |[ENOTSUP]
> > > | Not supported. The implementation does not support this feature of
> > > | the Realtime Option Group.
> > > 
> > > Both these descriptions have some resemblance with the interpretation
> > > of AVERROR_NOTSUPP -> feature not implemented.
> > > 
> > > Since the semantics of AVERROR_NOTSUPP -> feature not
> > > implemented is already covered by AVERROR_PATCHWELCOME,
> 
> no it is not,
> Feature not implemented
> and
> Implementing this feature is welcome
> 
> are 2 seperate things
> 
> similarly
> 
> "not implementable"
> "requested operation nonsensical"
> "we dont want this implemented"
> "disabled at compile time, rerun configure"
> 
> are all semantically different
> 
> also you cannot redefine the POSIX error codes to mean something else than
> they mean.

So taking into account the considerations of Howard and yours, it
seems that we can agree on simply dropping AVERROR_NOTSUPP and use
AVERROR(ENOSYS) instead.

We'll use AVERROR_PATCHWELCOME when a feature is not implemented and
we want and can implement it, and we'll use AVERROR(ENOSYS) in all the
other cases (feature non-implementable, requested operation
nonsensical, feature implementable but we don't want to implement it,
feature disabled at compile time etc...).

See attached patch.
-- 
FFmpeg = Fascinating & Fanciful Merciful Portentous Ecumenical Game



More information about the ffmpeg-devel mailing list