The RTSP-over-HTTP tunneling support in our RTSP server code doesn't
yet work properly - that's why it's commented out.
At present, we support RTSP-over-HTTP tunneling for RTSP clients only.
--
Ross Finlayson
Live Networks, Inc.
http://www.live555.com/
__
What's wrong with putting your meta-data in another stream that is
time synchronized with the H264 stream. I believe that is the
intended way to do such a thing in RTP.
It depends. Is the meta-data really specific to individual video
frames? If so, then it's better to include it in the video
Title: Re: [Live-devel] RTP Extension
What's wrong with putting your meta-data in another stream that is time
synchronized with the H264 stream. I believe that is the intended way
to do such a thing in RTP.
Just curious,
Matt S.
Yedidia Amit wrote:
I mean to RTP Header Extens
Hi All,
I have extended the Live 555 server to support RTSPoverHTTPTunnelling.
I am testing it using openRTSP...
does open RTSP tunnelling(full fledged)..
that is receiving the response for the RTSP request on the GEt channel and
sending requests to teh server on the POST channel.
When i am testi
I managed to track the cause of the disconnection down.
It seems that the later connection's RR packets are not handled by
RTPTransmissionStats::noteIncomingRR but by the
RTSPServer::RTSPClientSession::incomingRequestHandler1.
That's strange. When the RTSP server handles the RTSP "PLAY"
com
1.Why the parsers in the Live libarary are working with try and catch?
When a parser runs into the end of its input buffer (which could
happen anywhere within the parsing code), it needs to temporarily
stop parsing, request new input data, and then return to the event
loop. C++ language exce
I mean to RTP Header Extension. and thank you for your answer.
what I am trying to do is adding meta data per frame to a H264 RFC3984 stream.
another way which cross my mind is to put this meta data in NAL with
unspecified NAL type (24-31).
But I need it to interop with clients which dont suppor
Hi Ross, All
1.Why the parsers in the Live libarary are working with try and catch?
2. If I am implementing DeviceSouce which deliver H264 nals threw socket
(as you recommended), how should I know which nal is the last NAL fo the
AccessUnit (last nal in frame)?
Regards,
Amit Yedidia
Elbit Sys
Hi Ross,
I managed to track the cause of the disconnection down.
It seems that the later connection's RR packets are not handled by
RTPTransmissionStats::noteIncomingRR but by the
RTSPServer::RTSPClientSession::incomingRequestHandler1.
Every RR fills the buffer up and when the buffer is finally
I mean to RTP Header Extension. and thank you for your answer.
what I am trying to do is adding meta data per frame to a H264 RFC3984
stream.
another way which cross my mind is to put this meta data in NAL with
unspecified NAL type (24-31).
But I need it to interop with clients which dont support
What is the proper way to imlement adding RTP extension in Live555?
it depends what you mean by "RTP extension".
If you're referring to just implementing a new RTP payload format,
then this is easy - just define and implement your own subclasses of
"MultiFramedRTPSink" (for sending) and "Mult
Hi,
What is the proper way to imlement adding RTP extension in Live555?
Thanks,
Amit Yedidia
The information in this e-mail transmission contains proprietary and business
sensitive information. Unauthorized interception of this e-mail may constitute
a violation of law. If you are not the in
Are there any plans to implement the RTSPClient using aynchronous
network I/O as specified in the "To do" section of the website?
Yes.
And if so, what time frame are we looking at?
I don't like to give 'timeframes'; however, this is a high-priority item.
--
Ross Finlayson
Live Networks, Inc
Hi Ross,
Are there any plans to implement the RTSPClient using aynchronous network I/O
as specified in the "To do" section of the website?
And if so, what time frame are we looking at?
Thanks,
Ralf
--
This message is subject to the CSIR's copyright terms and conditions, e-mail
legal notice,
14 matches
Mail list logo
