> But when doing this, i am getting the following error
> "BasicTaskScheduler::SingleStep(): select() fails: Bad file descriptor". I
> have no idea why i am getting this. An indea of the root cause ?
That error message means that the socket number in the “Groupsock” object is
invalid - perhaps
Thanks Ross.
2016-03-10 13:55 GMT-03:00 Ross Finlayson :
>> I have implemented a live streamer based on live555 and am using a
>> receiver based on libav.
>>
>> The live stream is received and played back correctly.
>>
>> My issue is that, although I set a time value to the presentation time
>> (f
Le vendredi 11 mars 2016, 04:58:47 Ross Finlayson a écrit :
> To do this, do the following:
>
> 1/ Use a “BasicUDPSource” to receive the raw-UDP Transport Stream.
> 2/ Feed this to a “MPEG2TransportStreamFramer” (to generate proper
> 'presentation time’s for the Transport Stream packets).
> 3/ Fe
> I have implemented a live streamer based on live555 and am using a
> receiver based on libav.
>
> The live stream is received and played back correctly.
>
> My issue is that, although I set a time value to the presentation time
> (fPresentationTime) in live555, the pts of the packet is always 0
> We are trying to read the RTCP RR details from the RTPSink's transmission DB.
> But those entries are not getting cleared even after receiving the RTCP BYE
> from the corresponding SSRCs.
> Is it done purposefully?
Yes. However, old SSRCs (and their database entries) do get ‘reaped’ (i.e.,
cl
> We are developing a multicast streaming server based on testMP3Streamer test
> program.
> Would like to get the round trip time(RTT) from the RTCP RR report.
>
> As I see, we are creating a RTCPInstance.
> How can we calculate the RTT from the RTCP RR report (based on
> (Time_Now-TimeOf_LSR)-
> I am trying to convert a MPEG2-TS stream, with 1xH264 video stream inside to
> a RTP multicast stream. I tried various functions, but nothing seems to work.
>
> Below is the code of my latest attempt (srcip = 127.0.0.1, srcport = 6402,
> dstip = 226.0.16.1, dstport = 6500). Of course, rtsp->en
Thanks for this suggestion. Copying and pasting the command between a couple
places had caused a change in the quotes. Once I fixed them my problem was
solved
From: live-devel [mailto:live-devel-boun...@ns.live555.com] On Behalf Of Jeff
Shanab
Sent: Wednesday, March 09, 2016 6:52 PM
To: LIVE
A correction: I am now able to reproduce the problem (so you no longer need to
send me the proxy server output that illustrates this).
Yes, this is definitely a bug. (When the second (audio+video) client
disconnects, the proxy server should be sending a RTSP “PAUSE” command only for
the audio
Thanks David for taking the time to answer my question.
I will try and see what the RTPDemux information has.
If I come up with something I will post it back here.
BR,
Franco
2016-03-10 6:59 GMT-03:00 David Cassany Viladomat :
> Hi franco,
>
> I think the issue you are experimenting is more re
Title: Samsung Enterprise Portal mySingle
Hi,
We are trying to read the RTCP RR details from the RTPSink's transmission DB.
But those entries are not getting cleared even after receiving the RTCP BYE from the corresponding SSRCs.
Is it done purposefully?
How can remove legacy SSRC's from my
Sorry, but I still can’t reproduce this. Please run your “live555 Proxy
Server” with the “-V” flag (for verbose output), and post (to this mailing
list) the output that illustrates the problem that you are seeing. Perhaps
that will tell me what is happening for you.
Ross Finlayson
Live Netwo
Hi Ross,
Thank you for the reply. Yes It is PAUSE That is sent to the camera.
(mistake in subject). The scenario in which I am facing the issue, is as
follows
* REGISTER a camera with Video and Audio subsession.
* Client 1 - openRTSP -v rtsp://ip:port/streamid (VIDEO ONLY CLIENT)
* Clien
Hi franco,
I think the issue you are experimenting is more related to FFMPEG or LIBAV
than Live555. I am trying achieve the same you are tyring to, however I
don't have much time to dedicate to it. Up to now I am using the same
approach you suggested (using the current system time in PTS == 0 and
I’m sorry, but I haven’t been able to reproduce this at all. When there are
two (or more) ‘front-end’ clients streaming the same stream from the proxy
server, then the closure of any one of the ‘front-end’ streams has no effect on
what the proxy server does. It’s only when the *last* ‘front-en
15 matches
Mail list logo
