Hi. In addition to the SEQ problem that I'm working on right now, I have other 2 issues which I might be able to tinker: 1) There is a delay between the moment initial connection to RTSP is done ,and before the read__packet() returns the first packet. The delay is about 2-3 seconds, and then all the packets for these seconds are returned at once (one after another), with AV_NOPTS_VALUE for their PTS/DTS value. Other RTSP implementation don't seem to have this issue. Any idea if it's as intended, and there any setting which controls it? If not, is it a know issue, which can be solved? 2) It seems that current RTSP implementation doesn't send keep-alive signals - at least it seems as I'm stopping receiving packets after 20 sec, and then I need to reconnect to the source. There seems to be a patch that was submitted, but no indication whether it was really accepted. Any idea what it's status, and what should be improved there to support more keep-alive scenarios? Thanks for your help!
Hi, On Tue, Jul 14, 2009 at 11:21 AM, Stas Oskin<stas.oskin at gmail.com> wrote:
2) It seems that current RTSP implementation doesn't send keep-alive signals - at least ?it seems as I'm stopping receiving packets after 20 sec, and then I need to reconnect to the source.
There seems to be a patch that was submitted, but no indication whether it was really accepted. Any idea what it's status, and what should be improved there to support more keep-alive scenarios?
I will commit it once the RTP/ASF is in (final patch is pending), I think it was accepted already. Ronald
I will commit it once the RTP/ASF is in (final patch is pending), I think it was accepted already.
Hi. Is this the latest version of the patch? http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2009-March/064576.html Regards.
Hi Stas, On Tue, Jul 14, 2009 at 11:40 AM, Stas Oskin<stas.oskin at gmail.com> wrote:
Is this the latest version of the patch?
http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2009-March/064576.html
Yes. Ronald
Hi Ronald.
http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2009-March/064576.html
Yes.
On related note, for RTSP authentication, do I also need the http.c patch listed here? http://archives.free.net.ph/message/20090228.175031.eba1475c.fr.html Thanks for information!
Hi, On Wed, Jul 15, 2009 at 8:52 AM, Stas Oskin<stas.oskin at gmail.com> wrote:
http://archives.free.net.ph/message/20090228.175031.eba1475c.fr.html
Should already have been applied.. (?) Ronald
Hi. Should already have been applied.. (?)
Yes, indeed. Problem is that recent source seems to be quite off of these 2 patches (keep alive and rtsp auth). If I adapt the patches for these changes, should I post them here, or wait until you finalize them? Regards.
Hi, On Wed, Jul 15, 2009 at 12:30 PM, Stas Oskin<stas.oskin at gmail.com> wrote:
If I adapt the patches for these changes, should I post them here, or wait until you finalize them?
You should post if you distribute. Otherwise, don't worry, I have them adapted in my local tree and will commit once RTP/ASF is done. Ronald
You should post if you distribute. Otherwise, don't worry, I have them adapted in my local tree and will commit once RTP/ASF is done.
Would you mind sharing these 2 adapted patches (keep-alive and RTSP auth) in this thread, so I could use the latest version of them? I then could test them with several sources I have, and report here if any problems. Thanks!
Hi Stas, On Wed, Jul 15, 2009 at 3:21 PM, Stas Oskin<stas.oskin at gmail.com> wrote:
You should post if you distribute. Otherwise, don't worry, I have them adapted in my local tree and will commit once RTP/ASF is done.
Would you mind sharing these 2 adapted patches (keep-alive and RTSP auth) in this thread, so I could use the latest version of them?
RTSP keep-alive attached, the other is pending b/c it's not updated yet. :-). This one might not be completely uptodate but it's the last I have. Ronald
Hi. RTSP keep-alive attached, the other is pending b/c it's not updated
yet. :-). This one might not be completely uptodate but it's the last I have.
Thanks for sharing, then I will send you back the RTSP auth as well, the moment I have it working for your consideration.
Hi Stas, On Wed, Jul 15, 2009 at 5:14 PM, Stas Oskin<stas.oskin at gmail.com> wrote:
RTSP keep-alive attached, the other is pending b/c it's not updated yet. :-). This one might not be completely uptodate but it's the last I have.
Thanks for sharing, then I will send you back the RTSP auth as well, the moment I have it working for your consideration.
Yes please do, thanks. Ronald
Hi. RTSP keep-alive attached, the other is pending b/c it's not updated
yet. :-). This one might not be completely uptodate but it's the last I have.
This is quite strange, but I do see the patch in the FFMPEG tree already? If yes, and the patch already active, any idea why the stream disconnects after 20 sec? Regards.
Hi, On Wed, Jul 15, 2009 at 5:48 PM, Stas Oskin<stas.oskin at gmail.com> wrote:
This is quite strange, but I do see the patch in the FFMPEG tree already?
Oh, apparently I applied it. Oops. :-).
If yes, and the patch already active, any idea why the stream disconnects after 20 sec?
Dunno, what is the URI for testing? Ronald
Hi.
after 20 sec?
Dunno, what is the URI for testing?
It's an inner one - I will see if I can expose it. Point is, that as I inspected the keep-alive patch, I seen that it basically sends OPTIONS RTSP request every timeout seconds. Now, there are two questions here: 1) Other sources have keep-alive of 60 - same as the predefined value, but this one has 80, so this might be related. 2) No matter how much time I inspected with Wireshark the communications, I didn't see any RTSP keep alive being sent to any of the sources. Any idea if it travels via other packets? Regards.
Hi Stas, On Jul 15, 2009, at 6:53 PM, Stas Oskin <stas.oskin at gmail.com> wrote:
after 20 sec?
Dunno, what is the URI for testing?
1) Other sources have keep-alive of 60 - same as the predefined value, but this one has 80, so this might be related.
2) No matter how much time I inspected with Wireshark the communications, I didn't see any RTSP keep alive being sent to any of the sources.
Well, if timeout is 80 then we send keepalives every 80/2, so 40sec. Try increasing this frequency.
Hi. Well, if timeout is 80 then we send keepalives every 80/2, so 40sec. Try
increasing this frequency.
Any idea how to check if the keep-alive being sent at all? Because from this code, it seems that keep-alives are sent only for WMS/Real-player, while in my case the server is a standard RTP one ( has "server" in it's SDP server field), but it still specifies "timeout" in sdp. Now, I did small patch, and just removed the "(rt->server_type == RTSP_SERVER_WMS || rt->server_type == RTSP_SERVER_REAL)" to test. I still don't see any RTSP OPTIONS packets being sent in the sniffer. Any idea why is that and how to see these RTSP packets?
This is quite strange, but I do see the patch in the FFMPEG tree already?
If yes, and the patch already active, any idea why the stream disconnects after 20 sec?
Also, attached are two patches after being applied to r19400: rtspAuth - patch worked out of box. keepAlive - had to change one location to have it "working" (return that it rejects all already merged changes, instead of failing one hunk).
rtspAuth - patch worked out of box.
Sorry, correction - attached the updated one. I didn't touch the line numbers in patch - patch seems to be able to locate the required spot according to lines perfectly.
Stas Oskin wrote:
Hi.
In addition to the SEQ problem that I'm working on right now, I have other 2 issues which I might be able to tinker:
1) There is a delay between the moment initial connection to RTSP is done ,and before the read__packet() returns the first packet. The delay is about 2-3 seconds, and then all the packets for these seconds are returned at once (one after another), with AV_NOPTS_VALUE for their PTS/DTS value.
This should only happen if you receive a stream that has been started before the player (basically, you cannot receive reliable timestamps until the first RTCP SR packet has been received).
Other RTSP implementation don't seem to have this issue.
Some players return fake timestamps until the first RTCP SR packet is received (for example, if receiving a multicast stream with "vlc file.sdp" you can see a discontinuity in the audio or in the video after few seconds).
Any idea if it's as intended, and there any setting which controls it? If not, is it a know issue, which can be solved?
If you are playing an "rtsp://" URL, ensure that the server sends an RTCP SR packet as soon as the player starts playing the stream.
2) It seems that current RTSP implementation doesn't send keep-alive signals
Not sure what a "keep-alive" signal is... Where is it described in the standard? For sure, the RTCP RR packets sent by libavformat contain unreliable information, but this seems to be by design. Luca
Hi, On Tue, Jul 14, 2009 at 11:45 AM, Luca Abeni<lucabe72 at email.it> wrote:
Not sure what a "keep-alive" signal is... Where is it described in the standard?
No, it's Real/MS crap. Ronald
No, it's Real/MS crap.
Surprisingly I see quite several of RTSP sources (non-MS/Real) which follow this spec, probably to "optimize" the communication. Regards.
Hi, On Tue, Jul 14, 2009 at 11:49 AM, Stas Oskin<stas.oskin at gmail.com> wrote:
No, it's Real/MS crap.
Surprisingly I see quite several of RTSP sources (non-MS/Real) which follow this spec, probably to "optimize" the communication.
It's how you set a standard in practice. No RFC, simply push the market to slavishly follow.. Worked for IE... Ronald
Ronald S. Bultje wrote:
Hi,
On Tue, Jul 14, 2009 at 11:45 AM, Luca Abeni<lucabe72 at email.it> wrote:
Not sure what a "keep-alive" signal is... Where is it described in the standard?
No, it's Real/MS crap.
Ah, ok... So, I think this should be mentioned when talking about "RTSP issues" :) Luca
Ah, ok... So, I think this should be mentioned when talking about "RTSP
issues" :)
You right about this one of course :).
Hi. the player (basically, you cannot receive reliable timestamps until the
first RTCP SR packet has been received).
Just a question about design - why to keep these packets buffered (as it seems to happen now), and not return them immediately to user, for his decision? Other RTSP implementation don't seem to have this issue.
Some players return fake timestamps until the first RTCP SR packet is
received (for example, if receiving a multicast stream with "vlc file.sdp" you can see a discontinuity in the audio or in the video after few seconds).
Thanks for the explanation, this clarifies the matter indeed. Any good scheme to fake these timestamps? Maybe just taking the first X correct timestamps, then approximate backwards for the non-stamped packets? Regards.
Stas Oskin wrote:
Hi.
the player (basically, you cannot receive reliable timestamps until the
first RTCP SR packet has been received).
Just a question about design - why to keep these packets buffered (as it seems to happen now), and not return them immediately to user, for his decision? Well, the RTSP demuxer does not keep packets buffered. I guess they are buffered by libavformat during av_find_stream_info(). So, I suspect this is application's decision (I think you can avoid calling av_find_stream_info(), and fill all the codecs' parameters by yourself...).
Other RTSP implementation don't seem to have this issue. Other RTSP implementation return unreliable PTSs.
Some players return fake timestamps until the first RTCP SR packet is
received (for example, if receiving a multicast stream with "vlc file.sdp" you can see a discontinuity in the audio or in the video after few seconds).
Thanks for the explanation, this clarifies the matter indeed.
Any good scheme to fake these timestamps? You can modify libavformat/rtpdec.c:finalize_packet(), and write some random value in pkt->pts if s->last_rtcp_ntp_time == AV_NOPTS_VALUE (for example, you can add an "else pkt->pts = timestamp;). But then be prepared to see timestamps discontinuities and all kinds of problems.
Maybe just taking the first X correct timestamps, then approximate backwards for the non-stamped packets? Well, after receiving the first RTCP SR (and having the first reliable timestamp), you can do some kind of backward extrapolation... But this is something that the application must do, not something for libavformat.
Luca
Hi. Just a question about design - why to keep these packets buffered (as it
seems to happen now), and not return them immediately to user, for his decision?
Well, the RTSP demuxer does not keep packets buffered. I guess they are buffered by libavformat during av_find_stream_info(). So, I suspect this is application's decision (I think you can avoid calling av_find_stream_info(), and fill all the codecs' parameters by yourself...).
Thanks, I will try to fill it out myself and see how it works.
Maybe just taking the first X correct timestamps, then approximate
backwards for the non-stamped packets?
Well, after receiving the first RTCP SR (and having the first reliable timestamp), you can do some kind of backward extrapolation... But this is something that the application must do, not something for libavformat.
Indeed, I prefer to do it in the application side. Regards.
Hi, On 7/15/2009 12:06 AM, Luca Abeni wrote:
[...]
Maybe just taking the first X correct timestamps, then approximate backwards for the non-stamped packets? Well, after receiving the first RTCP SR (and having the first reliable timestamp),
What about discarding packets until RTCP SR is received ? It is streaming, user won't care about loosing a few frames at the beginning but will definitely prefer having correct timestamps, like this thread proves. -- Baptiste COUDURIER GnuPG Key Id: 0x5C1ABAAA Key fingerprint 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA FFmpeg maintainer http://www.ffmpeg.org
What about discarding packets until RTCP SR is received ?
It is streaming, user won't care about loosing a few frames at the beginning but will definitely prefer having correct timestamps, like this thread proves.
That what I actually do now, but I still want to be able to process these frames if needed.
On 7/15/2009 12:16 PM, Stas Oskin wrote:
What about discarding packets until RTCP SR is received ?
It is streaming, user won't care about loosing a few frames at the beginning but will definitely prefer having correct timestamps, like this thread proves.
That what I actually do now, but I still want to be able to process these frames if needed.
Interesting, what for ? -- Baptiste COUDURIER GnuPG Key Id: 0x5C1ABAAA Key fingerprint 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA FFmpeg maintainer http://www.ffmpeg.org
Hi, On Wed, Jul 15, 2009 at 3:23 PM, Baptiste Coudurier<baptiste.coudurier at gmail.com> wrote:
On 7/15/2009 12:16 PM, Stas Oskin wrote:
What about discarding packets until RTCP SR is received ?
It is streaming, user won't care about loosing a few frames at the beginning but will definitely prefer having correct timestamps, like this thread proves.
That what I actually do now, but I still want to be able to process these frames if needed.
Interesting, what for ?
- data prefetch (imagine wanting an internal buffer, skipping the first 3sec b/c of delay and then having to wait an *additional* 3 seconds to build up the internal buffer; of course the 3s is a random number but you get the idea) - not all RTSP streams are live Ronald
On 7/15/2009 12:30 PM, Ronald S. Bultje wrote:
Hi,
On Wed, Jul 15, 2009 at 3:23 PM, Baptiste Coudurier<baptiste.coudurier at gmail.com> wrote:
On 7/15/2009 12:16 PM, Stas Oskin wrote:
What about discarding packets until RTCP SR is received ?
It is streaming, user won't care about loosing a few frames at the beginning but will definitely prefer having correct timestamps, like this thread proves. That what I actually do now, but I still want to be able to process these frames if needed. Interesting, what for ?
- data prefetch (imagine wanting an internal buffer, skipping the first 3sec b/c of delay and then having to wait an *additional* 3 seconds to build up the internal buffer; of course the 3s is a random number but you get the idea)
What's the frequency of RTCP SR ? I also wonder how other implementations manage to somehow returns timestamps better (even if unreliable) than libavformat, and it seems to suit some users better.
- not all RTSP streams are live
I could understand the RTCP SR problem when it is live, but I cannot when it's not live, can you please explain the principles ? Though I wonder why the first thing the server send is not a RTCP SR, I guess I'm not understanding the concept. -- Baptiste COUDURIER GnuPG Key Id: 0x5C1ABAAA Key fingerprint 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA FFmpeg maintainer http://www.ffmpeg.org
What's the frequency of RTCP SR ? I also wonder how other implementations manage to somehow returns timestamps better (even if unreliable) than libavformat, and it seems to suit some users better.
I was explained here quite well by Luca, that other implementations just extrapolate the missing timestamps.
- not all RTSP streams are live
I could understand the RTCP SR problem when it is live, but I cannot when it's not live, can you please explain the principles ? Though I wonder why the first thing the server send is not a RTCP SR, I guess I'm not understanding the concept.
I think this quite common - at least in my case there are consistent missed packets because the SR was not received yet.
Baptiste Coudurier wrote: [...]
- data prefetch (imagine wanting an internal buffer, skipping the first 3sec b/c of delay and then having to wait an *additional* 3 seconds to build up the internal buffer; of course the 3s is a random number but you get the idea)
What's the frequency of RTCP SR ?
There is no fixed frequency, but the minimum distance between two RTCP SR packets is 5s (in practice, packets will arrive at the maximum possible frequency, so you will very likely see an RTCP SR every 5s).
I also wonder how other implementations manage to somehow returns timestamps better (even if unreliable) than libavformat
They don't (it is impossible :). What libavformat does is to return AV_NOPTS_VALUE until a correct PTS can be computed. Other applications have no "no PTS" concept and generally return unreliable timestamps. This means that the first 2 or 3 seconds of live streams will be out of A/V synch, and a timestamp discontinuity will be seen as soon as the first RTCP SR packet arrives. Note that this only happens with live streams: most of the "rtsp://" streams are VoD, and in this case there is no problem (libavformat immediately returns correct PTSs)
- not all RTSP streams are live
I could understand the RTCP SR problem when it is live, but I cannot when it's not live, can you please explain the principles ?
The problem does not happen for non-live streams (at least: I use libavformat's RTP demuxer on daily basis, and I only see this delay with live streams).
Though I wonder why the first thing the server send is not a RTCP SR, I guess I'm not understanding the concept.
For broadcast-like streams sent over multicast, there is no concept of "first packet"... So, servers generally send the RTCP SR periodically (note that there also might be other delays when receiving live streams, because the first received frame generally is not a reference frame). Luca
- data prefetch (imagine wanting an internal buffer, skipping the first 3sec b/c of delay and then having to wait an *additional* 3 seconds to build up the internal buffer; of course the 3s is a random number but you get the idea)
You actually quite nailed it :).
Ronald S. Bultje wrote:
Hi,
On Wed, Jul 15, 2009 at 3:23 PM, Baptiste Coudurier<baptiste.coudurier at gmail.com> wrote:
On 7/15/2009 12:16 PM, Stas Oskin wrote:
What about discarding packets until RTCP SR is received ?
It is streaming, user won't care about loosing a few frames at the beginning but will definitely prefer having correct timestamps, like this thread proves. That what I actually do now, but I still want to be able to process these frames if needed. Interesting, what for ?
- data prefetch (imagine wanting an internal buffer, skipping the first 3sec b/c of delay and then having to wait an *additional* 3 seconds to build up the internal buffer; of course the 3s is a random number but you get the idea) - not all RTSP streams are live
For non-live streams, the problem does not exist (an RTCP SR arrives as a first packet). Luca
On Wed, Jul 15, 2009 at 10:41:38AM -0700, Baptiste Coudurier wrote:
Hi,
On 7/15/2009 12:06 AM, Luca Abeni wrote:
[...]
Maybe just taking the first X correct timestamps, then approximate backwards for the non-stamped packets? Well, after receiving the first RTCP SR (and having the first reliable timestamp),
What about discarding packets until RTCP SR is received ?
It is streaming, user won't care about loosing a few frames at the beginning but will definitely prefer having correct timestamps, like this thread proves.
i agree the user likely wont care about loosing a few frames but the user might care about extra delay, i mean something hypothetical like "why does ffplay need 10sec before playback starts while barfoo starts immedeatly ..." [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Many things microsoft did are stupid, but not doing something just because microsoft did it is even more stupid. If everything ms did were stupid they would be bankrupt already.
Hi Michael, Michael Niedermayer wrote: [...]
It is streaming, user won't care about loosing a few frames at the beginning but will definitely prefer having correct timestamps, like this thread proves.
i agree the user likely wont care about loosing a few frames but the user might care about extra delay, i mean something hypothetical like "why does ffplay need 10sec before playback starts while barfoo starts immedeatly ..."
Well, this problem is not limited to RTP... I saw it in the past when receiving MPEG TSs from DVB cards, or compressed MJPEG video from webcams (I do not remember if the problem also affects DV input from firewire). I believe the solution here is to allow av_find_stream_info() to return earlier... I tried to do something about it in the past, but I got sidetracked by other issues. Anyway, I'll try to look again at this in next week. Luca
Michael Niedermayer wrote:
On Wed, Jul 15, 2009 at 10:41:38AM -0700, Baptiste Coudurier wrote:
Hi,
On 7/15/2009 12:06 AM, Luca Abeni wrote:
[...]
Maybe just taking the first X correct timestamps, then approximate backwards for the non-stamped packets? Well, after receiving the first RTCP SR (and having the first reliable timestamp), What about discarding packets until RTCP SR is received ?
It is streaming, user won't care about loosing a few frames at the beginning but will definitely prefer having correct timestamps, like this thread proves.
i agree the user likely wont care about loosing a few frames but the user might care about extra delay, i mean something hypothetical like "why does ffplay need 10sec before playback starts while barfoo starts immedeatly ..."
ffplay currently is the faster to come up with something to see most of the time... (since it does almost no buffering while others buffer some frame before actually playing)... lu - almost alive again... -- Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero
On Sat, Jul 18, 2009 at 04:35:37PM +0200, Luca Barbato wrote:
Michael Niedermayer wrote:
On Wed, Jul 15, 2009 at 10:41:38AM -0700, Baptiste Coudurier wrote:
Hi,
On 7/15/2009 12:06 AM, Luca Abeni wrote:
[...]
Maybe just taking the first X correct timestamps, then approximate backwards for the non-stamped packets? Well, after receiving the first RTCP SR (and having the first reliable timestamp), What about discarding packets until RTCP SR is received ?
It is streaming, user won't care about loosing a few frames at the beginning but will definitely prefer having correct timestamps, like this thread proves.
i agree the user likely wont care about loosing a few frames but the user might care about extra delay, i mean something hypothetical like "why does ffplay need 10sec before playback starts while barfoo starts immedeatly ..."
ffplay currently is the faster to come up with something to see most of the time... (since it does almost no buffering while others buffer some frame before actually playing)...
playing streams received over a network like the internet (compared to something designed to guratee low latency low packet loss) requires buffering so ffplay is not better in this respect. It just will freeze as soon as a packet is delayed. The only way i could see to reduce initial buffering delay would be to receive data quicker than to play it so the buffer reaches a less critical state quickly .. [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
... defining _GNU_SOURCE... For the love of all that is holy, and some that is not, don't do that. -- Luca & Mans
Hi. On same subject here - is it possible to specify the server that I want to use TCP over HTTP streaming? AKA QuickTime HTTP tunneling? Live555/VLC have such option, I wonder if FFMPEG has it too, or how complicated it would be to add one? Regards.
Stas Oskin wrote:
Hi.
On same subject here - is it possible to specify the server that I want to use TCP over HTTP streaming?
There is support for tcp but last time I looked you don't have it wired to an ffplay option (yet)
AKA QuickTime HTTP tunneling?
I think it isn't patch welcome (or wait for a month ^^)
Live555/VLC have such option, I wonder if FFMPEG has it too, or how complicated it would be to add one?
rtsp-interleave (so you use the tcp rtsp connection to deliver rtcp and rtp) is standard and relatively easy to implement, http-tunnel isn't standard and the best documentation is looking at someonelse code... lu -- Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero
Hi. rtsp-interleave (so you use the tcp rtsp connection to deliver rtcp and
rtp) is standard and relatively easy to implement, http-tunnel isn't standard and the best documentation is looking at someonelse code...
I'm planning to start working on HTTP tunneling - was there any development ni this area? Regards.
Hi Stas, On Mon, Aug 24, 2009 at 5:04 AM, Stas Oskin<stas.oskin at gmail.com> wrote:
rtsp-interleave (so you use the tcp rtsp connection to deliver rtcp and rtp) is standard and relatively easy to implement, http-tunnel isn't standard and the best documentation is looking at someonelse code...
I'm planning to start working on HTTP tunneling - was there any development ni this area?
No, not yet. Ronald
Hi.
rtsp-interleave (so you use the tcp rtsp connection to deliver rtcp and
rtp) is standard and relatively easy to implement, http-tunnel isn't standard and the best documentation is looking at someonelse code...
I'm planning to start working on HTTP tunneling - was there any development ni this area?
No, not yet.
Were there any new developments regarding RTSP over HTTP? I'm starting to work on it, and wanted to know if there any existing code-base I should take into account. Also, what will be the best location in code to plug-in such integration? Thanks.
Hi Stas, On Mon, Nov 2, 2009 at 1:07 PM, Stas Oskin <stas.oskin at gmail.com> wrote:
Were there any new developments regarding RTSP over HTTP? I'm starting to work on it, and wanted to know if there any existing code-base I should take into account.
Nothing yet.
Also, what will be the best location in code to plug-in such integration?
Probably rtsp.c, or a new rtsp_http.c if you need alot of new code. But really, that's not very important. Don't forget to use the existing http.c URI code (url_open("http://...")) rather than re-making a new implementation yourself. Ronald
Hi.
Also, what will be the best location in code to plug-in such integration?
Probably rtsp.c, or a new rtsp_http.c if you need alot of new code. But really, that's not very important.
Don't forget to use the existing http.c URI code (url_open("http://...")) rather than re-making a new implementation yourself.
Thanks for the advice, will post here any questions / updates.
Hi. After being some on and off time on this, I finally found a detailed description for this protocol (curiously there was no documentation from Apple on this): http://www.ibr.cs.tu-bs.de/cgi-bin/dwww?type=file&location=/usr/share/doc/dss/RTSP_Over_HTTP.pdf.gz It confirms my initial idea, that client starts with a single request, then it passively reads what server sends it. So my idea for implementation is as following: 1) I will first try to extend rtsp.c (to reuse the existing functions). 2) Will use url_open() to start initial connection. 3) Then will packetize the data as it comes, and forward to necessary FFMPEG functions. Any suggestions / improvements to this approach? Thanks.
Hi Stas, On Thu, Nov 26, 2009 at 6:13 AM, Stas Oskin <stas.oskin at gmail.com> wrote: [..]
Any suggestions / improvements to this approach?
No, I'd get going and do it. :-). I hope it works! Ronald
Hi. No, I'd get going and do it. :-). I hope it works!
Thanks - I hopefully would have good results to share soon!
Regards.
Hi Luca.
On same subject here - is it possible to specify the server that I want to
use TCP over HTTP streaming?
There is support for tcp but last time I looked you don't have it wired to an ffplay option (yet)
Any idea how to turn on the RTSP over TCP connection? Which parameter I need to specify?
rtsp-interleave (so you use the tcp rtsp connection to deliver rtcp and rtp) is standard and relatively easy to implement, http-tunnel isn't standard and the best documentation is looking at someonelse code...
Just to verify, rtsp-interleave is RTSP over TCP, right? I more familiar with Live555/VLC terms. Thanks again.
Hi Stas, On Mon, Aug 24, 2009 at 9:29 AM, Stas Oskin<stas.oskin at gmail.com> wrote:
On same subject here - is it possible to specify the server that I want to use TCP over HTTP streaming?
There is support for tcp but last time I looked you don't have it wired to an ffplay option (yet)
Any idea how to turn on the RTSP over TCP connection? Which parameter I need to specify?
There is no ffplay parameter yet, there is just code in rtsp.c to do it, but no API or ffplay option for it. See make_setup_request() and its caller.
Just to verify, rtsp-interleave is RTSP over TCP, right?
Yes. Ronald
Hi. There is no ffplay parameter yet, there is just code in rtsp.c to do
it, but no API or ffplay option for it. See make_setup_request() and its caller.
There is no such function in make_setup_request(), only the following code: else if (protocol_mask & (1 << RTSP_PROTOCOL_RTP_TCP)) { if (transport[0] != '\0') pstrcat(transport, sizeof(transport), ","); snprintf(transport + strlen(transport), sizeof(transport) - strlen(transport) - 1, "RTP/AVP/TCP"); } The protocol_mask seems to be hard-coded on UDP indeed. Was the TCP mode tested anywhere? Regards.
Hi Stas, On Mon, Aug 24, 2009 at 4:22 PM, Stas Oskin<stas.oskin at gmail.com> wrote:
The protocol_mask seems to be hard-coded on UDP indeed.
Was the TCP mode tested anywhere?
Yes, I test it all the time. Ronald
Hi.
Yes, I test it all the time.
Actually it seems I used an outdated version of ffmpeg. Inspecting this code, it seems the connection mode is set via the URL: 01177 option_list = strchr(path, '?'); 01178 if (option_list) { 01179 /* remove the options from the path */ 01180 *option_list++ = 0; 01181 while(option_list) { 01182 /* move the option pointer */ 01183 option = option_list; 01184 option_list = strchr(option_list, '&'); 01185 if (option_list) 01186 *(option_list++) = 0; 01187 /* handle the options */ 01188 if (strcmp(option, "udp") == 0) 01189 lower_transport_mask = (1<< RTSP_LOWER_TRANSPORT_UDP <http://cekirdek.pardus.org.tr/%7Eismail/ffmpeg-docs/rtsp_8h.html#7d32a74979e7e6f60215f11789b3e02eb31d84d023a1ff6f491af197a446bba7>); 01190 else if (strcmp(option, "multicast") == 0) 01191 lower_transport_mask = (1<< RTSP_LOWER_TRANSPORT_UDP_MULTICAST <http://cekirdek.pardus.org.tr/%7Eismail/ffmpeg-docs/rtsp_8h.html#7d32a74979e7e6f60215f11789b3e02e89dd2ec02679eec3d7de20a8aa33f022>); 01192 else if (strcmp(option, "tcp") == 0) 01193 lower_transport_mask = (1<< RTSP_LOWER_TRANSPORT_TCP <http://cekirdek.pardus.org.tr/%7Eismail/ffmpeg-docs/rtsp_8h.html#7d32a74979e7e6f60215f11789b3e02e365e39b94c7df02faa14d371d49a6a9b>); Something like this: rtsp://xxx.xxx.xxx.xxx:554/test.sdp?tcp ? Regards.
Something like this:
rtsp://xxx.xxx.xxx.xxx:554/test.sdp?tcp
?
Hmm, I'm getting the following error: " Error while parsing header" I will override it via code, but I'd still appreciate a correct syntax for this :).
Hi again.
Hmm, I'm getting the following error:
" Error while parsing header"
I will override it via code, but I'd still appreciate a correct syntax for this :).
Ok, the problem seems to be because Darwin Streaming Server doesn't like the ?tcp bit at the end of the URL, other servers seem to work fine. Maybe we can think of another way to specify this parameter? Regards.
Hi, On Mon, Aug 24, 2009 at 7:53 PM, Stas Oskin<stas.oskin at gmail.com> wrote:
Maybe we can think of another way to specify this parameter?
Well yes this whole options-via-URI is stupid-as-hell. We shouldn't touch the URI, period. Maybe add an char **options or so as an extra argument? AVOptions integration in demuxers? I don't know. Any of the real API heroes wants to give opinions? Ronald
On Tue, Aug 25, 2009 at 09:57:37AM -0400, Ronald S. Bultje wrote:
Hi,
On Mon, Aug 24, 2009 at 7:53 PM, Stas Oskin<stas.oskin at gmail.com> wrote:
Maybe we can think of another way to specify this parameter?
Well yes this whole options-via-URI is stupid-as-hell. We shouldn't touch the URI, period. Maybe add an char **options or so as an extra argument? AVOptions integration in demuxers? I don't know. Any of the real API heroes wants to give opinions?
AVOptions are "integrated" with demuxers already, what is the problem? if the target is a demuxer it should be easy to pass options, OTOH its maybe more tricky with a protocol instead of a demuxer ... [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB If a bugfix only changes things apparently unrelated to the bug with no further explanation, that is a good sign that the bugfix is wrong.
Hi, On Tue, Aug 25, 2009 at 10:16 AM, Michael Niedermayer<michaelni at gmx.at> wrote:
AVOptions are "integrated" with demuxers already, what is the problem? if the target is a demuxer it should be easy to pass options, OTOH its maybe more tricky with a protocol instead of a demuxer ...
Any examples that I could look at? :-). Ronald
On Tue, Aug 25, 2009 at 10:29:09AM -0400, Ronald S. Bultje wrote:
Hi,
On Tue, Aug 25, 2009 at 10:16 AM, Michael Niedermayer<michaelni at gmx.at> wrote:
AVOptions are "integrated" with demuxers already, what is the problem? if the target is a demuxer it should be easy to pass options, OTOH its maybe more tricky with a protocol instead of a demuxer ...
Any examples that I could look at? :-).
any line of the options array from libavformat/options.c and the corresponding line from AVFormatContext are an example for (de)muxers for protocols i think theres no clean system in place ... [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Republics decline into democracies and democracies degenerate into despotisms. -- Aristotle
Hi. Well yes this whole options-via-URI is stupid-as-hell. We shouldn't
touch the URI, period. Maybe add an char **options or so as an extra argument?
I found another issue related to TCP. rtsp.c doesn't specify "unicast;" on non-WMS rtsp servers in TCP mode, which several common RTSP servers don't like. Attached a patch that handles this. Regards.
Hi Stas, On Tue, Aug 25, 2009 at 1:21 PM, Stas Oskin<stas.oskin at gmail.com> wrote:
rtsp.c doesn't specify "unicast;" on non-WMS rtsp servers in TCP mode, which several common RTSP servers don't like.
RDT/Real refuses with unicast, WMS refuses without, so please make sure to test all appropriately before changing it. Ronald
Hi.
RDT/Real refuses with unicast, WMS refuses without, so please make sure to test all appropriately before changing it.
Maybe a special case for RDT/Real to check for this issue? Regards.
Baptiste Coudurier wrote:
Hi,
On 7/15/2009 12:06 AM, Luca Abeni wrote:
[...]
Maybe just taking the first X correct timestamps, then approximate backwards for the non-stamped packets? Well, after receiving the first RTCP SR (and having the first reliable timestamp),
What about discarding packets until RTCP SR is received ?
Well, I think that this should be application's decision, and not a policy hardcoded in the library... If we deliver all the frames to the application (marking the ones with unreliable PTSs), it is of course free to discard the first frames, until the PTSs become reliable.
It is streaming, user won't care about loosing a few frames at the beginning but will definitely prefer having correct timestamps, like this thread proves.
I am with you on this... Everything the application has to do is to discard first frames having PTS = AV_NOPTS_VALUE. Luca
Stas Oskin wrote:
Thanks for your help!
Just a question, what are you using as server? lu -- Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero
participants (6)
-
baptiste.coudurier＠gmail.com -
lu_zero＠gentoo.org -
lucabe72＠email.it -
michaelni＠gmx.at -
rsbultje＠gmail.com -
stas.oskin＠gmail.com