[FFmpeg-devel] [PATCH] rtsp protocol : teardown packet not sent

Nicolas George george at nsup.org
Tue Oct 20 22:17:01 CEST 2015


Le nonidi 29 vendémiaire, an CCXXIV, Nicolas Adenis-Lamarre a écrit :
> Probably i misunderstood again, but,
> I don't understand however in which case an application would use a
> callback to avoid any io at all.
> For example, i don't understand why ffplay, when a user close the window,
> choose to avoid any io at all.

Any I/O can cause delay. When the user close the window, they want it to
close immediately, not in five seconds. Even a tenth of a second gives a
noticeable lag, it is not annoying in itself bug will cause the user to
unconsciously consider the program badly finished.

> in ffplay.c, would it be ok to change
> static int decode_interrupt_cb(void *ctx) { return ctx->abort_request; }
> by
> static int decode_interrupt_cb(void *ctx) { return 0; }
> ?
> (i don't think so)

Look at the code:

static void stream_close(VideoState *is)
{
    /* XXX: use a special url_shutdown call to abort parse cleanly */
    is->abort_request = 1;
    SDL_WaitThread(is->read_tid, NULL);

The author was well aware of the issue, but interrupting the network flow is
simpler.

Note that it should not matter: the teardown packet is required by the
protocol, but the closure is also transmitted by other means (probably TCP
RST or ICMP, depending on the transport layer used), and if the server does
not take it into account, blame it for being stupid.

> * change the user application to not return 1 from the callback
> => i could, but i'm afraid that even ffplay which is a part of ffmpeg has
> the problem.

As you can see, a correct implementation of the shutdown would be
appreciated. IMHO, the best way of doing so would be:

- queue an immediate display of having taken the user's request into
  account;

- start clean shutdown;

- wait a configurable amount of time and revert to interrupting the I/O.

All this is necessary because there are various causes for blocking; if
ffplay is stuck waiting for more data in the middle of a packet header but
the network went down, interrupting the I/O is the only solution.

> 2015-10-20 19:20 GMT+02:00 Michael Niedermayer <michael at niedermayer.cc>:

Please remember not to top-post on this list; if you do not know what it
means, look it up.

Regards,

-- 
  Nicolas George
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20151020/7fd696fd/attachment.sig>


More information about the ffmpeg-devel mailing list