[FFmpeg-cvslog] In retry_transfer_wrapper, do not check url_interrupt_cb,

[Michael Niedermayer]

On Sun, Mar 06, 2011 at 11:48:22AM +0100, Nicolas George wrote:
> Le sextidi 16 vent?se, an CCXIX, Michael Niedermayer a ?crit?:
> > a 2 or 3 level abort should be used. Like unix TERM & KILL
> 
> It is an interesting solution, but is it necessary?
> 
> With the check for url_interrupt_cb at the end of the loop, the code works,
> just as it has worked for a long time. It just needs a little clarification
> in the documentation.
> 
> Adding this multi-level interrupt system would not solve any problem
> currently known. And when a problem will actually arise, we do not know
> whether this will be enough to solve it.
> 
> Designing a solution without a problem is rarely a good idea.
> 
> For now, I think it would be best to just restore the check of
> url_interrupt_cb at the end of the loop and document that url_interrupt_cb
> makes the protocol it has interrupted unusable.

we cannot make the writing protocol unuseable as a first level meassure to quit

when q is pressed we need to write, trailer + index + seek back to begin +
update filesize and frame number in header for some formats.
when q is pressed we didnt even yet start writing the index and trailer

multiple levels are the obvious solution.
level 1, simply stop in the user app cleanly (this needs no call back value)
level 2, hard abort any reading protocols returning incomplete data if needed
level 3, hard abort any writing protocols this will cause inconsistence between
         what is written and what the muxer wanted to write. Depending on file
         this may render the file unplayable or some frames at the end missing

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

I have often repented speaking, but never of holding my tongue.
-- Xenocrates
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-cvslog/attachments/20110306/28831ab4/attachment.pgp>