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

[Reimar Döffinger]

On 7 Mar 2011, at 14:14, "Ronald S. Bultje" <rsbultje at gmail.com> 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.
> 
> 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? What if I have an application that has 1000
> URLContexts and I only want to quit one of them?

Does that need anything beyond the context as argument?
However that does not really help that much, since a lot of time you'll really want to know from which AVFormatContext it comes.
This really is a change that needs to be demonstrated to work before implementing it I think.