From: Michel C. <mc...@ma...> - 2003-10-06 20:28:03
|
With all the information that we get in previous emails, it seems that it will be a lot of work to write an xine input plugin to support standard rtsp, especially for someone like me that is not familiar with all the architecture of xine and rtsp. Is it possible to create a group of programmers, from xine, live.com and me that can work together on this ? Now we know : 1.We can get a test server from live.com 2.We can keep the actual code in xine rtsp input plugin to keep the ability to play streams from old Real server. 3.xine does assume one single input. 4. Will it be possible for the input plugin to serialize the two streams to feed one demuxer ? Yes, you could do this - but you would need to define your own, new format for representing multiplexed RTP data, and make the rest of xine understand this format. (E.g., you couldn't use an existing multiplexed data format like MPEG Program Streams, because RTP data isn't necessarily MPEG.) 5. live.com is in c++ and xine in c . Complaints about C++ might have been credible 15 years ago, but not in 2003. Pretty much every platform on which you could imagine porting Xine will have C++ compiler support as well as C. (With MPlayer, the only real portability issue that has arisen has been that you need to use the same version of GCC to build both the LIVE.COM libraries and the rest of MPlayer.) 6.Rtp can contain different formats for audio and video. RTP sessions can contain audio and video streams that use completely unrelated codecs (and also other types of stream, such as time-synchronized text (e.g., subtitles)). The audio and video RTP streams could even - in principle - come from different sources. So do WE WORK ALL TOGETHER on this project ? Michel Cunha |
From: Ross F. <fin...@li...> - 2003-10-06 21:28:43
|
>So do WE WORK ALL TOGETHER on this project ? Sounds good to me. FYI, I think the "liv...@li..." mailing list is the best forum for continued discussion of this project - that is the mailing list for discussion of how to make use of the LIVE.COM libraries in new applications. (Note, though, that you need to be s subscriber to that list in order to post to it. To subscribe, visit <http://lists.sourceforge.net/lists/listinfo/live-devel>) Ross Finlayson LIVE.COM <http://www.live.com/> |
From: Mike M. <mel...@pc...> - 2003-10-06 21:49:18
|
Hi Yezdi Tamboli, hi John Mavity, I don't know who you 2 are, and I hope it doesn't bug you that people keep CC'ing you on these emails. On 6 Oct 2003, Michel Cunha wrote: > With all the information that we get in previous emails, it seems that > it will be a lot of work to write an xine input plugin to support > standard rtsp, especially for someone like me that is not familiar with > all the architecture of xine and rtsp. I will be the first to admit that I have a severe problem with over-simplifying stuff. But I really do not see what would be so hard about making a practical RTSP plugin for xine from scratch. Here is the kind of thing I am envisioning: - xine gets request to play RTSP MRL - RTSP input plugin is invoked to handle it - RTSP plugin resolves domain name, connects and issues DESCRIBE request - RTSP gets response, issues SETUP requests for each track in the stream, makes note of RTP port numbers specified to server - RTSP sets up UDP ports to listen for incoming data - RTSP issues PLAY request - data starts coming in via one or more UDP ports, the RTSP plugin buffers the data and sends it to the demuxer requested - new "pass-through" demuxer (not unlike the CDDA "demuxer") would be deployed to mediate between the RTSP plugin and the decoders - ideally, random seeking could eventually be supported, which is specified in the standard and hopefully supported by servers Am I missing anything crucial? I mean besides the fact that it would not be a fully RTSP-compliant client? As long as it is enough to interact with practical server implementations. As for Real, I do not see how their standard could be so deviant that it could not be special-cased into the same input plugin. But again, I may oversimplify. -- -Mike Melanson |
From: Michel C. <mc...@ma...> - 2003-10-07 16:34:58
|
ok, I will start programming a RTSP plugin for xine from scratch Le lun 06/10/2003 =C3=A0 17:49, Mike Melanson a =C3=A9crit : > Hi Yezdi Tamboli, hi John Mavity, I don't know who you 2 are, and I hop= e > it doesn't bug you that people keep CC'ing you on these emails. >=20 >=20 > On 6 Oct 2003, Michel Cunha wrote: >=20 > > With all the information that we get in previous emails, it seems tha= t > > it will be a lot of work to write an xine input plugin to support > > standard rtsp, especially for someone like me that is not familiar wi= th > > all the architecture of xine and rtsp. >=20 > I will be the first to admit that I have a severe problem with > over-simplifying stuff. But I really do not see what would be so hard > about making a practical RTSP plugin for xine from scratch. Here is the > kind of thing I am envisioning: >=20 > - xine gets request to play RTSP MRL > - RTSP input plugin is invoked to handle it > - RTSP plugin resolves domain name, connects and issues DESCRIBE reques= t > - RTSP gets response, issues SETUP requests for each track in the strea= m, > makes note of RTP port numbers specified to server > - RTSP sets up UDP ports to listen for incoming data > - RTSP issues PLAY request > - data starts coming in via one or more UDP ports, the RTSP plugin buff= ers > the data and sends it to the demuxer requested > - new "pass-through" demuxer (not unlike the CDDA "demuxer") would be > deployed to mediate between the RTSP plugin and the decoders > - ideally, random seeking could eventually be supported, which is > specified in the standard and hopefully supported by servers >=20 > Am I missing anything crucial? I mean besides the fact that it would no= t > be a fully RTSP-compliant client? As long as it is enough to interact w= ith > practical server implementations. >=20 > As for Real, I do not see how their standard could be so deviant > that it could not be special-cased into the same input plugin. But agai= n, > I may oversimplify. > -- > -Mike Melanson |
From: Mike M. <mel...@pc...> - 2003-10-07 17:05:02
|
On 7 Oct 2003, Michel Cunha wrote: > ok, I will start programming a RTSP plugin for xine from scratch Are you sure you have a good handle on it? Now that I have a plan mapped out, I was hoping to get to it in the next week. I know it will take a few iterations of testing to get it workable. -- -Mike Melanson |
From: Michel C. <mc...@ma...> - 2003-10-07 17:14:45
|
ok, since you have a plan mapped out and prepared to get to it in the next week I will let you do it, since you do understand better than me the xine architecture. However, if you need help (programming or/and testing), I would be happy to help you :)) Michel Le mar 07/10/2003 =C3=A0 13:04, Mike Melanson a =C3=A9crit : > On 7 Oct 2003, Michel Cunha wrote: >=20 > > ok, I will start programming a RTSP plugin for xine from scratch >=20 > Are you sure you have a good handle on it? Now that I have a plan > mapped out, I was hoping to get to it in the next week. I know it will > take a few iterations of testing to get it workable. >=20 > -- > -Mike Melanson |
From: Michel C. <mc...@ma...> - 2003-10-27 19:43:53
|
Hello Mike, I was wondering what are your progress in adding ISO RTSP support in xine input plugin ? Need any help for testing ? Michel Cunha Le mar 07/10/2003 =C3=A0 13:04, Mike Melanson a =C3=A9crit : > On 7 Oct 2003, Michel Cunha wrote: >=20 > > ok, I will start programming a RTSP plugin for xine from scratch >=20 > Are you sure you have a good handle on it? Now that I have a plan > mapped out, I was hoping to get to it in the next week. I know it will > take a few iterations of testing to get it workable. >=20 > -- > -Mike Melanson |
From: Mike M. <mel...@pc...> - 2003-10-28 05:19:46
|
On 27 Oct 2003, Michel Cunha wrote: > Hello Mike, > > I was wondering what are your progress in adding ISO RTSP support in > xine input plugin ? Believe it or not, progress is being made. In fact, I have it all mapped out on my whiteboard next to my computer how I plan to do this. > Need any help for testing ? When the first rev gets in the tree, yes. Thanks... -- -Mike Melanson |
From: Ross F. <fin...@li...> - 2003-10-07 17:45:47
|
> > I will be the first to admit that I have a severe problem with > > over-simplifying stuff. Yes :-) > But I really do not see what would be so hard > > about making a practical RTSP plugin for xine from scratch. Here is the > > kind of thing I am envisioning: > > > > - xine gets request to play RTSP MRL > > - RTSP input plugin is invoked to handle it > > - RTSP plugin resolves domain name, connects and issues DESCRIBE request OK, but would you also like to be able access password-protected sessions? If so, you also want to support digest authentication here. > > - RTSP gets response, issues SETUP requests for each track in the stream, > > makes note of RTP port numbers specified to server Are you familiar with SDP? Do you know the difference between static and dynamic payload type codes (i.e., the use of the optional "a=rtpmap:" line)? Are you also familiar with the optional "a=fmtp:" line, and how it contains 'config' information that's necessary for playing MPEG-4 streams? Do you know how to specify (optional) transport of RTP-over-TCP (useful for clients who are behind a firewall)? > > - RTSP sets up UDP ports to listen for incoming data Do you also know how unicast and multicast sessions are handled differently (in SDP and RTSP)? Would you also like to be able to play sessions that are specified using SDP files (rather than always using RTSP to retrieve the SDP information)? Are you also familiar with RTCP, how it relates to RTP, and how NTP-format timestamps in RTCP "SR" packets are used to synchronize audio and video RTP streams (by providing them with accurate presentation times)? > > - RTSP issues PLAY request OK, this part is fairly easy (at least, as long as you're not using digest authentication :-) > > - data starts coming in via one or more UDP ports, the RTSP plugin buffers > > the data and sends it to the demuxer requested Do you understand that there are different specifications (called "RTP payload formats") for how different codecs use RTP? I.e., the rules for how MPEG-1 or 2 (audio or video) data is packed into RTP packets are different from how MPEG-4 audio data is packed into RTP packets, which are different from how MPEG-4 video data is packed into RTP packets, which in turn are different from how motion-JPEG video is packed into RTP packets, which are different from how H.261 or H.263 video is packed into RTP packets, which are different from how QCELP audio is packed into RTP packets, which are different from how PCM audio is packed into RTP packets, etc. etc. etc. Thus, it's not possible to write a single "RTP stack" that handles all possible media types. Instead, you need specific implementations for each codec that you want to support. (Note each of the files named "*RTPSource*" in the LIVE.COM "liveMedia" library. Each of these implement - using C++ subclassing - a different RTP payload format (i.e., codec).) > > - new "pass-through" demuxer (not unlike the CDDA "demuxer") would be > > deployed to mediate between the RTSP plugin and the decoders Yes, this is the part that you folks would need to write, in any case. (It would be analogous to the "demux_rtp*" code that I wrote for MPlayer.) > > Am I missing anything crucial? Just a bit :-) > I mean besides the fact that it would not > > be a fully RTSP-compliant client? As long as it is enough to interact with > > practical server implementations. If you're going to do this at all, why not do it right? The LIVE.COM "liveMedia" library is ~30,000 lines of code. Duplicating this functionality - even for a bare-bones RTSP/RTP/RTCP client only - would be *at least* 10,000 lines of code. Is this something that you *really* want to do, just because some of you are in a 1980s time warp, and have a morbid fear of C++? As with MPlayer, the use of a RTSP/RTP/RTCP plugin - using the LIVE.COM library - could be optional (through #ifdefs, specified at config time). Those people who don't want to use it won't need it (and won't be bothered with C++). Ross. |
From: Mike M. <mel...@pc...> - 2003-10-07 18:35:57
|
On Tue, 7 Oct 2003, Ross Finlayson wrote: > Are you familiar with SDP? Do you know the difference between static and [...] [...] [are you familiar with this, that, and the other thing] No, not intimately familiar. But I am always eager to learn. I understand network programming, I know where the RFCs are, and I know how to use a protocol analyzer. Have you ever read the full Quicktime spec? It's big, it's scary, and it's not entirely necessary to implement 100% of it in order to play 99.9% of all QT files in the wild. xine's QT demuxer does a great job of playing just about any QT file you can find, even though it implements a fraction of the total spec. My point is that it can't possibly be necessary to implement every piece of every spec in order to accomodate 99% of the streams out there. But hang out because I might be wrong. But I sincerely appreciate your email as it gives me a lot of issues I need to consider in the new implementation. To the standard "reinventing the wheel" critique, allow me to retort: I have the time and I have the desire, not just for reimplementation, but also for understanding the concepts. I don't know much about network multimedia transport and this is a good opportunity to learn. One more thing: Please understand that C++ is "different" than C, not necessarily "better" by any stretch of the imagination. Thanks... -- -Mike Melanson |