> With the RTCPInstance SRHandler callback, is there any method
> to determine which UDP port the sender is using for RTCP?
No, and this is why you should support RTSP - in both your sender and receiver.
We spent a lot of effort standardizing this protocol, and I spent a lot of
time implementin
> How bombard live555 by streams "*.ts" to test the performance of live555
> in terms of throughput and number of streams
> that can diffuse it in the same time.
(I'm assuming that the above sentence was intended to be a question...)
You can do this easily just by running multiple RTSP clien
Please replace your version of "JPEGVideoRTPSource.cpp" with this attached version - that adds debugging output - and recompile. Then, when you get the crash again, please send us the diagnostic output again. With luck, this will help track down the problem some more.
Ross FinlaysonLive Networks,
Hi,
With the RTCPInstance SRHandler callback, is there any method
to determine which UDP port the sender is using for RTCP?
I'm writing a receiver for a point-to-point RTP stream.
The stream is initiated by using a method other than RTSP.
The code does not know what RTP and RTCP ports that the sen
>> Based on the testRTSPClient example, I've gotten a stable RTSP connection
>> working on my target platform; in this case to a video+audio RTSP source.
>> But, now I'm struggling to figure out the next step. My custom MediaSink
>> classes do not receive any frame data via afterGettingFrame()
Thanks Ross,
> Based on the testRTSPClient example, I've gotten a stable RTSP connection
> working on my target platform; in this case to a video+audio RTSP source.
> But, now I'm struggling to figure out the next step. My custom MediaSink
> classes do not receive any frame data via afterGetting
> I updated to the latest code (live.2013.01.25.tar) and have been running the
> modified testRTSPClient using DrMemory. The exception occurs at DrMemory
> Error #10 and #11. The Windows app crash dialog is then displayed and after
> closing that the remaining DrMemory info is printed (as can be
> Based on the testRTSPClient example, I've gotten a stable RTSP connection
> working on my target platform; in this case to a video+audio RTSP source.
> But, now I'm struggling to figure out the next step. My custom MediaSink
> classes do not receive any frame data via afterGettingFrame()
Th
> I want two know if testRTSPClient allows me to specify codec type and if it
> can give me single encoded frame every time afterGettingFrame() is invoked?
Yes. Look at the "DummySink" class that the "testRTSPClient" demo application
uses. Note, in particular, the (non-static) "DummySink::afte
Apologies in advance for following deluge. I'm new to Live555, RTP and
RTSP in general; and trying to gather resources to understand how to
consume video+audio streams.
Based on the testRTSPClient example, I've gotten a stable RTSP connection
working on my target platform; in this case to a video
Hi,
I want two know if testRTSPClient allows me to specify codec type and if it can
give me single encoded frame every time afterGettingFrame() is invoked? If not,
what would be my options to have support for H264 frame parsing in received bit
stream? I want to identify frame boundary in the en
> I could able to play MJPEG(640x480) and AAC streams fine in separate RTSP
> server media sessions. But, If I try to play both the streams through single
> RTSP server media session then I am getting the following results,
>
> · Some time video is very slow but audio is OK
> ·
Hi,
I could able to play MJPEG(640x480) and AAC streams fine in separate RTSP
server media sessions. But, If I try to play both the streams through single
RTSP server media session then I am getting the following results,
. Some time video is very slow but audio is OK
. So
> In order to bring RTP header extension support in live555, are you asking for
> a commercial support or a coding support ?
Right now all I'm saying is that it's not at the top of my 'to do' list.
Ross Finlayson
Live Networks, Inc.
http://www.live555.com/
_
> To use the example data that you used in your last email, this means that the
> data that you should copy to *fTo should be
> 09 10 00 00 00 01 67 42 C0 1F F4 02 00 30 D8 08 80 00 01 F4 ...
Oops, it turns out that this wasn't correct. The "00 00 00 01" in the data is
the 'start code', t
Hi Ross,
In order to bring RTP header extension support in live555, are you asking for a
commercial support or a coding support ?
Best Regards,
Michel.
[@@THALES GROUP RESTRICTED@@]
De : live-devel-boun...@ns.live555.com
[mailto:live-devel-boun...@ns.live555.c
Look, I don't know how much clearer I can be about this.
The data that you copy to *fTo should be a single NAL unit, AND NOTHING ELSE!
That means that there should not be ANY 'start code' or 'length prefix' or
anything else at the start of the data. (I thought I made this clear in my
last ema
Hi Ross,
>Remember that the data that you copy to *fTo should be a NAL unit, and nothing
>else. That means no start >code at the front. But it also means nothing else
>at the front - including your >'length prefix'.
>In other words - you need to omit the 'length prefix' when you copy the NAL
18 matches
Mail list logo
