[MPlayer-users] Re: status of the rtsp support NOVIRUS

[Luca Abeni]

Hi Ross,

I see your reply in the ml archive:

>>Sorry... I was not clear in my description of the problem... What I
>>wanted to say is that rtp_demux.cpp starts to discards packets and
never
>>ends to discard them. In other words, it never exit from that while()
>>cycle.
>
> Yes it does.  Notice the "break" statement in the middle of that 
> "while" 
> loop.  The code discards packets from one stream only as long as the
> packets' presentation times remain 1 second or more behind the other 
> stream.  Once that stream catches up (within 1 second), its packets
> will no longer be discarded.
Once again I did not explain the problem correctly, sorry :(
The problem is that the difference between the packets' presentation
times is about 3000 seconds... Hence, packets will no longer be
discarded after about 48 minutes.
I discovered this by defining DEBUG_PRINT_DISCARDED_PACKETS and by
adding some printf()s.

In my understanding the problem is due to the fact that after the
arrival of the first RTCP packet (I think it is a SR) a stream is
synchronized while the other one is not (hence, the packets'
presentation times of the two streams cannot be reliably compared).

I attach a patch that solves the problem for me... My code is very ugly,
but with this patch I can receive MP2 and MP4 streams through rtsp (for
MP4 stream, I also have to use the -fps option, because of another
problem that I am still investigating).

What the patch does is simply to wait for the streams to be synchronized
before beginning to play. In this way, I do not see the big difference
between audio and video timestamps, and everything works.
I also addess an usleep() to buffer some packets in the socket queue.

Now, the _real problem_ is that I am the only one seeing this issue, and
I cannot understand why :(
Do you have any idea about what can be wrong in my side? (What should
happen when the first RTCP packet arrives? How does mplayer+live.com
avoid to have only one stream syncronized?)
I am doing MP2 experiments vith vobStreamer (using some vobs that I got
from a DVD) and MP4 experiments with the darwing streaming server, and
with MPEG4IP. All the experiments are on a local network.

>>It is a 100Mbps ethernet... I don't know about MPEG-2 streaming, but I
>>know that it is enough for MP4, because I was able to succesfully
>>receive MP4 streams with the MP4IP client (mplayer + live.com failed,
as
>>for MP2).
>
> Can you give me an example of a (publically accessible) MPEG-4
> audio/video 
> "rtsp://" URL that fails for you (when running MPlayer+LIVE.COM)?
> That's something that should be working OK.
I set up a darwin streaming server and an mpeg4live server.
Unfortunately, they are on a local network and cannot be accessed from
outside. Anyway, the attached patch fixed the MP4 case too.


			Thanks again,
				Luca
-- 
_____________________________________________________________________________
Copy this in your signature, if you think it is important:
                               N O    W A R ! ! !



--
Email.it, the professional e-mail, gratis per te: http://www.email.it/f

Sponsor:
Navighi in cerca di sconti e offerte? Allora non perdere quest'occasione, clicca qui
Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=1814&d=23-9
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mp4.diff
Type: text/x-patch
Size: 2782 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-users/attachments/20030923/d5458410/attachment.bin>