Git Inbox Mirror of the ffmpeg-devel mailing list - see https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
 help / color / mirror / Atom feed
From: Anton Khirnov <anton@khirnov.net>
To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org>
Subject: Re: [FFmpeg-devel] [PATCH v2] fftools/ffmpeg_mux: fix reporting muxer EOF as error
Date: Sun, 23 Apr 2023 14:01:15 +0200
Message-ID: <168225127500.3843.6466868436482522174@lain.khirnov.net> (raw)
In-Reply-To: <3587873f-7b50-a98c-70ce-443aeb93b9ae@passwd.hu>

Quoting Marton Balint (2023-04-23 12:05:51)
> 
> 
> On Sun, 23 Apr 2023, Anton Khirnov wrote:
> 
> > Quoting Marton Balint (2023-04-23 11:42:48)
> >> On Sun, 23 Apr 2023, Anton Khirnov wrote:
> >>> Quoting Marton Balint (2023-04-23 11:12:38)
> >>>> This seems like yet another clash of AVERROR_EOF error codes coming from
> >>>> different places with different semantics. For
> >>>> av_interleaved_write_frame(), AVERROR_EOF is an error condition, so
> >>>> file encoding should fail,
> >>>
> >>> Why should it fail? I'd think a muxer returning EOF is the way to signal
> >>> non-error muxer-side termination.
> >>
> >> That would be an API change. AVERROR_EOF is not special in any way from
> >> other error codes for av_interleaved_write_frame. A muxer cannot signal
> >> non-error muxer side termination with existing API.
> >
> > All error codes (should) have a specific meaning. I cannot think of a
> > good reason for a muxer to return AVERROR_EOF to signal an error.
> > Can you?
> 
> Previously, we expeced users to treat any negative error code as error for 
> av_interleaved_write_frame().

I don't think we expect the users to do anything in particular in
responce to av_interleaved_write_frame() return codes. The doxy says
that it returns a negative error code on error, but the caller can
freely decide what to do with that information - this includes ignoring
it.

> This is what is documented. ffmpeg.c followed this approach. Don't you
> see the slightest problem if we suddenly change this?

Seems to me you're mixing ffmpeg CLI and lavf behavior. My claim is
entirely from the point of view of the CLI, and is this: if the muxer
returns AVERROR_EOF, then it should be treated as normal termination.
This is similar to how other components behave - e.g. a (bitstream)
filter can at any time decide to return EOF to its downstream,
terminating a stream even though more input is available.

You could argue that muxers should never return AVERROR_EOF and any
muxer that currently does so is buggy, but that is still compatible with
the above.

-- 
Anton Khirnov
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

  parent reply	other threads:[~2023-04-23 12:01 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-04-22 12:56 Zhao Zhili
2023-04-22 15:44 ` Anton Khirnov
2023-04-23  9:12   ` Marton Balint
2023-04-23  9:34     ` Anton Khirnov
2023-04-23  9:42       ` Marton Balint
2023-04-23  9:48         ` "zhilizhao(赵志立)"
2023-04-23  9:51         ` Anton Khirnov
2023-04-23 10:05           ` Marton Balint
2023-04-23 10:07             ` Nicolas George
2023-04-23 12:01             ` Anton Khirnov [this message]
2023-04-23 18:15               ` Marton Balint
2023-04-23 20:16                 ` Anton Khirnov
2023-04-24  9:09                   ` Marton Balint
2023-04-24  9:19                     ` Nicolas George
2023-04-24 10:02                     ` Anton Khirnov
2023-04-24 18:41                       ` Marton Balint
2023-04-24 19:24                         ` Anton Khirnov
2023-04-24 19:42                           ` Marton Balint
2023-04-24 21:08                             ` Anton Khirnov
2023-04-25 14:37                               ` Nicolas George
2023-04-24 20:41                         ` Nicolas George
2023-04-24 10:08                     ` Anton Khirnov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=168225127500.3843.6466868436482522174@lain.khirnov.net \
    --to=anton@khirnov.net \
    --cc=ffmpeg-devel@ffmpeg.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Git Inbox Mirror of the ffmpeg-devel mailing list - see https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

This inbox may be cloned and mirrored by anyone:

	git clone --mirror https://master.gitmailbox.com/ffmpegdev/0 ffmpegdev/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 ffmpegdev ffmpegdev/ https://master.gitmailbox.com/ffmpegdev \
		ffmpegdev@gitmailbox.com
	public-inbox-index ffmpegdev

Example config snippet for mirrors.


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git