"No, you don’t ‘set’ “fTo” to point to the data; you *copy* the data to the
address pointed to by “fTo”"
Yes, you are correct. I was using "loosey goosey" terminology here.
Specifically, I do something like this:
memmove(fTo, nal.p_payload ..
A bit more details on the crash I'm encountering.
We're using Live555 for live RTSP video streaming and it's been working
flawlessly for us. The video we stream we also save to disk using some
other mechanism. We are now in a situation where our clients would like to
play back the recorded files on demand, and so we're looking to extend our
RTSP s
I can probably roll this myself and/or guess at the value, but I'm curious
if there's an authoritative value somewhere that I can query to just get
this... What I'd like to do is, from my Live555 RTSP server, determine the
number of bytes sent, to all clients, per second.
We have a scenario where,
I am using Live555 at the moment to implement, among other things, a
two-way audio solution. People in one room (room A) can "call" people in
another room (room B) and carry on a conversation with them.
I implement this by a MediaSink-derived class (called SpeakerSink) which
handles receiving RTP
I'd like to have a single process expose two separate RTSP addresses:
rtsp://:/endpoint1
rtsp://:/endpoint2
...as opposed to having multiple video subsessions from one server media
session, I'd like two separate servers on different port numbers, etc. For
management (for us, anyway), it'll be eas
In general though it appears as though there's nothing that "standard RTSP
players" respect, right? Whatever we do we will most likely need to write
out own player?
On Thu, Jul 7, 2016, 8:53 AM Jeff Shanab wrote:
> Why not add a metadata subsession then you can put whatever you like in,
> for e
Hi, thanks for your great response.
There's actually a few reasons why we prefer using rtsp if possible. One of
which is the time-sensitive nature of the content: we are in hospitals and
delivering real time streams of patients. Being even a few seconds off
could mean a patient falling. I have see
I realize that, if there is a supported mechanism, that it's largely the
responsibility of the client (and therefore that this may not be a Live555
server concern), but I'm also curious about what it would take on the
server to implement stream switching.
Here is our scenario. I'm using Live555 to
Greetings,
Here is a link on how to modify the make files:
http://stackoverflow.com/questions/29041258/building-64bit-live555-with-visual-studio-2013
I don't have time to support it, but I also have an old fork of Live555
that has those modifications already (warning, this is old, so use at your
Awesome, so just to be clear, calling something like this:
const unsigned maxCNAMElen = 100;
unsigned char CNAME[maxCNAMElen + 1];
gethostname((char*)CNAME, maxCNAMElen);
CNAME[maxCNAMElen] = '\0'; // just in case
unsigned int destinationRtcpPortNumber = destinationRtpPortNumber +
I hope I'm not asking too many questions on this group. I *am* searching
through the archives, but I'm not always finding the answers I need.
Anyway, standard setup:
_taskScheduler = BasicTaskScheduler::createNew();
_usageEnvironment = BasicUsageEnvironment::createNew(*_taskScheduler);
.
57 AM Ben Rush wrote:
> This has happened to me a couple times while coding up things and I'd like
> to see if it's something stupid I'm doing, or whether I've uncovered a bug
> in Live555.
>
> I've got a class called "RoomClientStreamingServer" whi
I'm using SimpleRTPSink to send audio to a client. Works great. I have it
setup like this:
SimpleRTPSink* sink = SimpleRTPSink::createNew(this->envir(),
rtpGroupsock,
payloadFormatCode, fSamplingFrequency,
"audio", mimeType, fNumChannels);
.
RTCPInstance
Hi Ross,
Thanks for you feedback again. One question. I'm confused about the order
of operations, then. You claim I should call .changeDestinationparameters()
with the sender's IP on the rtcpGroupSock before invoking
RTCPInstance::createNew() on said socket, but before receiving the sender's
IP I
I'm creating an audio "client" using RTPSource. I have a custom
MediaSink-derived class which takes the traffic and routes it to my
computer's audio device. Works great.
What I'd like to do, however, is retrieve the sender's IP address (the IP
address of the sender which is sending traffic to the
Sure. And thanks, as usual, for your help. I'm sure some of the confusion
is a result of me, again, being very green. As I started typing this out I
started seeing where you're coming from, so I'll explain my situation and
then confirm that I understand what YOU'RE saying at the end.
Here is the b
Sorry if this is a double-post, as I think I sent the previous email to the
wrong list.
Ross,
>From a previous conversation we had, you mentioned it was possible, and
easy, to have "full-duplex" mode, in that RTPSink and RTPSource share a
Groupsock and therefore share a TCP/IP socket. I'm looking
if it's backchannel related, add require to it)
>
> The project uses UDP btw, I don't have it working with tcp yet.
>
> You will have to learn how LiveMedia works to get it done anyhow.
>
> Op 01-Jun-16 om 9:09 PM schreef Ben Rush:
>
> We have built a RTSP st
We have built a RTSP streaming server using Live555's server libraries:
RTSPServer* rtspServer = RTSPServer::createNew(*usageEnvironment,
StreamingOptions::PortNumber, NULL);
And so on. Works like a charm and we're very happy with it. What we're
needing now is a solution for two-way aud
Thanks for the response.
Well, the rabbit hole got deeper as I actually hard coded (as a hack,
obviously) the SR reports to always report 0 for the octet and packet
count. That did nothing. So my theory was proven to be incorrect. I'm going
to update the server code and try that.
We're talking wi
...sorry, I missed that you asked about audio exclusively as well. Yes, the
issue persists even when it's audio only.
On Wed, Apr 20, 2016 at 9:42 AM Ben Rush wrote:
> Ross,
>
> Thanks for your response. Here are your answers:
>
> 1) Any client that we've tested thus
Ross,
Thanks for your response. Here are your answers:
1) Any client that we've tested thus far continues to connect and stream
without issue after the Android phone connects, or after any other client
connects. This is strictly the ONLY client we've seen to have ANY problems
like this.
2) Comme
Yes, my apologies for being unclear. I can see now how what I said might be
difficult to understand. I will try to do better and be a bit more
pedantic.
I'm on Windows and I've built a RTSP server that connects to a camera and
serves both audio and video using the Live555 server libraries. I used
We've been using Live555 very successfully now for a while but have
encountered a quirk that is likely due to a bug or oddity in the media
player on Android 5.0 Lollipop. The problem is that it's becoming a bit of
a showstopper for us (a major client is using this particular version of
Android), an
ngineering for me is "same
> stuff, differnt language")
>
> c/c++ is the best cross platform compiled language for me
> python is the best cross platform scripting language for me.
>
> Having said that... Python was originally written on a c base and there
> are some bin
e much faster of
> course.
> What would be best done in C++ and what in Python ?
> Thanks in advance
> IR
>
>
>
> On Feb 7, 2016, at 12:43 AM, i...@interstrat.com wrote:
>
> Thanks very much Ben
> IR
>
> Sent from my iPhone
>
> On Feb 7, 2016, at 00:14, Ben
more information
about what I'm seeing?
Thanks again for all your help,
Ben
On Mon, Feb 8, 2016 at 10:24 AM Ben Rush wrote:
> OK. I got into work just a bit ago and was going to check on your initial
> question
>
> "Was this the *only* change that you had to make here"
OK. I got into work just a bit ago and was going to check on your initial
question
"Was this the *only* change that you had to make here".
But I believe it is. I will respond here in a couple hours with my final
answer there, just in case.
I totally appreciate why (I imagine most people using yo
I do not think you'll find much in the way of python support for Live555,
if that's what you're asking. Otherwise you can look at other open source
projects such as https://github.com/mhaller/pyffmpeg.
Browsing the newsgroup has been the best documentation I've found, next to
reading the source co
Ross,
Thanks for the swift response. As it happens, I am using a discrete framer
for just this reason (in hopes it'd make synchronization easier). Here is
the implementation of my createNewStreamSource:
FramedSource* H264LiveServerMediaSession::createNewStreamSource(unsigned
clientSessionID, unsi
Hello,
I have been experimenting with live555 for a week now and have had a high
level of success in using it to stream h264 video from a camera. Now I want
to add audio and I'm having some issues.
I've read through a lot of the forum content related to this and I'm either
doing something peculia
31 matches
Mail list logo
