[FFmpeg-cvslog] In retry_transfer_wrapper, do not check url_interrupt_cb,
Mon Mar 7 18:16:13 CET 2011
On Mon, Mar 07, 2011 at 08:14:34AM -0500, Ronald S. Bultje wrote:
> On Mon, Mar 7, 2011 at 7:55 AM, Martin Storsj? <martin at martin.st> wrote:
> > On Sun, 6 Mar 2011, Michael Niedermayer wrote:
> >> 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
> > Yes, I think something like this would be useful. A simple first step
> > would be without a distinction between level 2 and 3, only interpreting
> > the first 'q'/ctrl+c as a graceful "please don't transcode any more data,
> > start writing the trailer now", and only triggering url_interrupt_cb() on
> > the second one.
implemented, will push when it passes tests
> Before we put any more effort in url_interrupt_cb(), can we please
> kill it and replace it by something that works across instances,
> threads and so on?
work on what you want, let others work on what they want.
This is not your fork.
> What if I have an application that has 1000
> URLContexts and I only want to quit one of them?
Then you have a problem that isnt solved by my change, and a fix to your 1000
URLContexts might not solve the problem we actually have here.
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
it is not once nor twice but times without number that the same ideas make
their appearance in the world. -- Aristotle
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 198 bytes
Desc: Digital signature
More information about the ffmpeg-cvslog