On 16 August 2010 07:38, Martin Storsjö <[email protected]> wrote: > On Sun, 15 Aug 2010, Ronald S. Bultje wrote: > >> On Aug 15, 2010, at 5:34 AM, Luca Barbato <[email protected]> wrote: >> > On 08/15/2010 10:58 AM, Josh Allmann wrote: >> >> 0002 - Reinstate rtp_get_file_handles function that is slated for >> >> removal at the next major bump. We need to be able to get the RTCP fd >> >> from the rtpproto. >> > >> > Ok >> >> Can we instead introduce a rtp_get_rtcp_file_handle()? I removed the >> _handles() one, it's not good API. > > I'm ok with it either way. So a separate function for RTCP it is, then? > >> >> 0003 - Read RTCP packets from the RTSP demuxer. This might not be >> >> strictly necessary, but it guarantees we'll read a RTCP packet if one >> >> is available (without the availability of a RTP data packet). >> > >> > Ok, maybe you can factorize it a bit better on a later time. >> >> This woyld need to be factorized to support RDT status msgs, which happen >> over the actual RDT line. > > Is RDT received over rtp:// URLContexts? If that's the case, this patch > itself still is ok, you just won't ever get any data on the RTCP socket. > >> >> 0005 - Actual BYE support. This is really kinda incomplete. It only >> >> returns EOF, whereas we should be selectively removing the stream >> >> (theoretically we could have concurrent streams playing, and one BYEs >> >> while the others keep going). In the case where we get a BYE with only >> >> one stream left, perhaps an EOF would be appropriate then. >> > >> > Not sure when that would happen, seems unlikely enough to not be >> > considered now. >> > >> >> Right now, not much happens since the EOF is propagated back to the >> >> application layer. FFplay pretty much ignores it, although I suppose >> >> it could (should?) be patched to call av_close_input_stream, so it >> >> sends a proper TEARDOWN. >> > >> > Yup, it should do that, I wonder where the eof is lost. >> >> Teardown means no seek support after EOF, i.e. this behaviour is >> intentional. The teardown should only be sent on close. EOF really isn't >> special, it just stops getting more packets (= infinite loop)unless the user >> has done something (seek, close). > > As Ronald said in another message, use -autoexit with ffplay if you want > it to close the app at eof. > > I'm a bit undecided on how to handle this, if we should return EOF when > the first stream sends BYE, or only when we've got that on all streams? > > Josh, does the main servers (DSS, feng) send BYE at eof on all streams at > the end? Does DSS send BYE properly on live streams, too? >
Feng sends BYE at the end of the stream. DSS sends BYE only upon connection close (I've only been able to initiate this by closing from the client side; by the time dss's BYE hits, the socket's already been closed and the packet just bounces.) DSS doesn't seem to send any RTCP for live streams; is this supposed to be the responsibility of the sender -- in this case, ffmpeg? >From my reading of the RTP spec, it looks like that the DSS BYE behavior is more appropriate. BYEs seem designed with multi-party group chat in mind not RTSP or seekability, but this blurb implies that a BYE should only be sent out at connection close (RFC 3550, 6.3.4): "BYE SHOULD be the last packet sent with a given SSRC/CSRC" In that case, if we do get BYEs for all streams, then perhaps the proper action would be to send a TEARDOWN, since there is not supposed to be any more data coming in. > If all send BYE on all streams properly, perhaps we should wait for them > all. On the other hand, in normal RTSP at least, all streams exist for the > full duration of the stream (I think?), so you don't have to worry about > the case when one stream is finished but another one still is playing > properly for a longer time. > Alright, that is how it is done now. Josh _______________________________________________ FFmpeg-soc mailing list [email protected] https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc
