You are right, it is available. I tried to use it but it fails with
disInstr(arm): unhandled instruction: 0xEEBA7BC1
cond=14(0xE) 27:20=235(0xEB) 4:4=0 3:0=1(0x1)
immediately after the log message
"ProxyServerMediaSubsession["H264"]::createNewStreamSource".
--
Anton
2013/2/28 F
Hi Anton,
On 02/28/2013 08:39 AM, agrit...@cnord.ru wrote:
Hello,
I believe I found a huge memory leak in the rtsp proxy server. The
problem is that I can only reliably reproduce it on qemu-arm or
physical armv7 device. It doesn't happen when I run rtsp proxy on my
x86-64 machine. Moreover, it
Hello,
I believe I found a huge memory leak in the rtsp proxy server. The
problem is that I can only reliably reproduce it on qemu-arm or
physical armv7 device. It doesn't happen when I run rtsp proxy on my
x86-64 machine. Moreover, it only reveals when there are four or more
clients connected to
> To Ross, I assume... You're so insightful and you always seem to nail it on
> the head. Perhaps you can give me some guidance here again.
I already have. However, I'll try to explain again what I've said in the past.
In any case, this will be my last posting on this topic.
> I got my nam
To Ross, I assume... You're so insightful and you always seem to nail it
on the head. Perhaps you can give me some guidance here again.
I got my named-pipe (actually I think it was an anonymous pipe) on Windows
working with good quality, from my video source software, through Live555,
and out to
> I am trying to add VP8/VORBIS codecs to VLC when it uses your library to
> receive such streams.
> To do this I need to get the VORBIS parameters (included in the a=fmtp
> configuration line).
>
> I noticed you have some functions to parse this config string, so I
> tried to call parseGeneralCon
Hi Ross,
I am trying to add VP8/VORBIS codecs to VLC when it uses your library to
receive such streams.
To do this I need to get the VORBIS parameters (included in the a=fmtp
configuration line).
I noticed you have some functions to parse this config string, so I
tried to call parseGeneralConfigS
> The purpose is to get from the client end the presentation time that was sent
> by the server.
> By now the client presentation time start from gettimeofday and will be
> synchronized by the first RTSP Sender report.
You meant to say "RTCP Sender Report". But yes, that's correct.
> what I w
Ok, thanks for the answer.
Another issue when seeking a stream from your RTSP server, is that the
first packet after the seek has a PTS from before the seek. The
following packets are fine.
This confuses VLC when it tries to re-buffer after the seek.
Regards,
Sébastien.
__
Ross,
Perhaps I missed some pieces.
The purpose is to get from the client end the presentation time that was sent
by the server.
By now the client presentation time start from gettimeofday and will be
synchronized by the first RTSP Sender report.
I try to find a way to have a di
> Per my understanding, In function
> MultiFramedRTPSource::networkReadHandler1(), Live555 will create
> BufferedPacket and store them to fReorderingBuffer. These BufferedPackets are
> consumed by calling doGetNextFrame1(). I discovered that once, for any
> reason, the stored BufferedPackets ar
> 1. Does each frame of a video stream, e.g. the H264 stream contain an
> unique identifier?
You could probably use each frame's "presentation time" as a 'unique id'.
Ross Finlayson
Live Networks, Inc.
http://www.live555.com/
___
live-devel mailing lis
Hi,
Per my understanding, In function MultiFramedRTPSource::networkReadHandler1(),
Live555 will create BufferedPacket and store them to fReorderingBuffer. These
BufferedPackets are consumed by calling doGetNextFrame1(). I discovered that
once, for any reason, the stored BufferedPackets are pile
Hi All,
I am very new to both streaming and live555.
Basically, I want to achieve the following task:
I have a LAN and a RTSP video source machine. I want to do some CV
task e.g. face detection, on another machine, and display the result
in the form of continuous original video stream (with dete
14 matches
Mail list logo