Hi experts,
Have someone tested the functions used to deinterleave multi AMR frames in a
single RTP packet? Here I have a question on the method
AMRDeinterleave::deliverIncomingFrame.
I suspect this method can only support the scenario that one RTP packet
contains only one AMR frame.
My unders
The fix with which you provided me for the multicast destination
address embedded in the SETUP response does not appear to be
yielding video.
Well, beforehand you told me that it worked OK!
Anyway, the fix was to reimplement the "Socket::changePort()"
function (in "groupsock/NetInterface.cpp"
Ross:
The fix with which you provided me for the multicast destination address
embedded in the SETUP response does not appear to be yielding video. The
RTSP server and clients and hence the camera that I am testing against are
at a remote location where nobody was available until today. Since I
When a MPEG Transport Stream file is indexed (to produce an index
(.tsx) file), our code skips over PES headers, so that the resulting
index file points *only* to MPEG Elementary Stream video data, not
PES headers (or any other non-MPEG-video data). The 'trick play'
code uses this indexed vide
Also, H.264 is not a 'protocol' - it's a *codec*. RTP is the protocol.
--
Ross Finlayson
Live Networks, Inc.
http://www.live555.com/
___
live-devel mailing list
live-devel@lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel
we started to develop using H264 protocol and we have some questions
about it. We are using all the comunication with live555 to extract
data from an Ip Camera with protocol H264. We have single NAL unit
mode non-interleaved and we are having problems to decompress using
x264.
Unfortunately I
Dear Ross,
we started to develop using H264 protocol and we have some questions about
it. We are using all the comunication with live555 to extract data from an
Ip Camera with protocol H264. We have single NAL unit mode non-interleaved
and we are having problems to decompress using x264.
When we
