So after some digging it appears the slow down I see when using TCP is due to a
slow connection to the proxy. See the code in RTPInterface.cpp.
In the function RTPInterface::sendRTPorRTCPPacketOverTCP.
The first send of the header is non-blocking, the second send is blocking ( the
last paramete
I was performing the timestamping using gettimeofday as the timestamps, but
before temporarily queuing the samples. Once I moved the timestamping to
the track's deliverFrame method the problem was resolved.
Thanks for your help.
(First, when replying to a mailing list digest, please use a prope
> Thank you for your answer, you right, I modify data source class and, I
> think, problem solved.
>
> Class Frame is sublass FramedSource.
> void Frame::doGetNextFrame()
> {
>fFrameSize = 0;
>fNumTruncatedBytes = 0;
>
>get data code
>
>if (fFrameSize)
>FramedSource::afte
I didn't looked at appendix B. But given that at page 7 of the RFC it is
stated: "...Each table is an array of 64 values given in zig-zag order,
identical to the format used in a JFIF DQT marker segment..." then I agree
that it couldn't be possible to use all the code of the RFC specification.
The
Hello, Ross!
Thank you for your answer, you right, I modify data source class and, I
think, problem solved.
Class Frame is sublass FramedSource.
void Frame::doGetNextFrame()
{
fFrameSize = 0;
fNumTruncatedBytes = 0;
get data code
if (fFrameSize)
FramedSource::afterGetting
> Thank you very much for your suggestion.
> The testH264VideoToTransportStream application reads and in input file (h264)
> and converts it into .ts file. That’s great.
>
> But I need to connect to an IP camera which provides me H264/MPEG stream.
> instead of file I want to provide this live
