[FFmpeg-devel] Flushing remaining streams when one stream fails on av_interleaved_write_frame()

[Michael Niedermayer]

On Tue, Jan 14, 2014 at 01:58:05PM -0200, Ramiro Polla wrote:
> On Tue, Jan 14, 2014 at 1:58 AM, Michael Niedermayer <michaelni at gmx.at> wrote:
> > On Thu, Jan 09, 2014 at 01:58:15AM -0200, Ramiro Polla wrote:
> >> Hi,
> >>
> >> When one stream fails in av_interleaved_write_frame(), ffmpeg just
> >> quits. If there are multiple streams/files, it may be possible that
> >> the other streams/files are still OK. ffmpeg should at least try to
> >> flush the remaining streams so that they become valid files.
> >>
> >> Here is an example to reproduce the problem:
> >> $ mkdir 1
> >> $ ffmpeg -i input -f image2 "%d/x.jpg" output.mpg
> >>
> >> output.mpg will not be flushed properly, even though the problem is in image2.
> >>
> >> I tried to fix this by propagating the error from write_frame() but
> >> the point I got to is that ffmpeg hangs on reading from the input
> >> (attached patch is for reference, not for review). This whole
> >> input/output code with filterchains in ffmpeg is confusing to me. Can
> >> anyone shed some light on the proper way to either a) close just the
> >> misbehaving stream and keep on trying the other ones or b) flush and
> >> close all streams on error.
> >>
> >> Ramiro
> >
> >>  ffmpeg.c |   98 ++++++++++++++++++++++++++++++++++++++++++++-------------------
> >>  1 file changed, 69 insertions(+), 29 deletions(-)
> >> 365f871d295f127a47ddacd21a8e4ef6ce1461a0  0001-NOT-FOR-REVIEW.patch
> >> From 7d1c1b0f12aa871bd6630d9a69adff8182aacea4 Mon Sep 17 00:00:00 2001
> >> From: Ramiro Polla <ramiro.polla at gmail.com>
> >> Date: Thu, 9 Jan 2014 01:51:15 -0200
> >> Subject: [PATCH] NOT FOR REVIEW
> >
> > See: [FFmpeg-devel] [PATCH 3/3] ffmpeg: properly close down muxers on av_interleaved_write_frame() failure
> 
> That patchset works but, while flushing the streams that are still
> working, write_frame is still being called (and giving errors) for the
> failed stream.

better patchset posted

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

I have never wished to cater to the crowd; for what I know they do not
approve, and what they approve I do not know. -- Epicurus
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20140115/b20fc183/attachment.asc>