Re: [Live-devel] How framerate is passing to rtsp client

2016-04-06 Thread Paweł Domagalski
Thanks for help Ross. According to your hint I replaced H264VideoStreamFramer to H264VideoStreamDiscreteFramer and I removed start code from NAL units. Everything works perfectly now. Have a nice day. Paweł On 04/04/16 18:54, Ross Finlayson wrote: My first NAL analyzed by bitstream analyzer.

Re: [Live-devel] How framerate is passing to rtsp client

2016-04-04 Thread Ross Finlayson
> My first NAL analyzed by bitstream analyzer. > > !! Found NAL at offset 4 (0x0004), size 18 (0x0012) > XX 00 00 00 01 67 42 80 1E 95 A0 50 7C 84 00 00 0F > > NAL > forbidden_zero_bit : 0 > nal_ref_idc : 3 > nal_unit_type : 7 ( Sequence parameter

Re: [Live-devel] How framerate is passing to rtsp client

2016-04-04 Thread Paweł Domagalski
Hi Ross, 1. I know that is difference between presentation time and timestamp. I will be typing more accurately next time. 2. My encoder generates NALs with synchronization four bytes included at the beginning. My first NAL analyzed by bitstream analyzer. /!! Found NAL at offset 4 (0x0004),

Re: [Live-devel] How framerate is passing to rtsp client

2016-04-01 Thread Ross Finlayson
> I have compared logs from my rtsp server ( runned on embedded device) and > rtsp client ( runned on PC) and I found difference in timestamps. You mean “presentation time”, not “timestamp”. (Once again, you do not need to concern yourself with RTP timestamps - at all. Please don’t mention the

Re: [Live-devel] How framerate is passing to rtsp client

2016-04-01 Thread Paweł Domagalski
I have compared logs from my rtsp server ( runned on embedded device) and rtsp client ( runned on PC) and I found difference in timestamps. On the server has elapsed 4.7 s On the testRTSPClient has elapsed 1.6 s. First timestamps are similar but next one is +110 ms on the server and + 40 ms on

Re: [Live-devel] How framerate is passing to rtsp client

2016-03-31 Thread Ross Finlayson
The (64-bit) "presentation time” values are not passed directly from the server to the client; instead, they are transferred implicitly, using the (32-bit) RTP timestamps in each RTP packet, plus periodic RTCP packets that provide the mapping from RTP timestamp to “presentation time”. This is a

Re: [Live-devel] How framerate is passing to rtsp client

2016-03-31 Thread Paweł Domagalski
Thanks for quick response. Yes, there should be 11. I have tested a few values and I left last one by mistake. I am using camera so next frame never arrives earlier, so this value doesn't matter. I changed my code by adding non valid values fPresentationTime.tv_sec = 1; fPresent

Re: [Live-devel] How framerate is passing to rtsp client

2016-03-31 Thread Ross Finlayson
>> I am using testOnDemandRTSPServer example code from live555. I have wrote my >> implementation of DeviceSource class. I have set presentation time properly: >> >> gettimeofday(&fPresentationTime, NULL); >> fDurationInMicroseconds = 110; > > That’s your problem. You’re telling the server

Re: [Live-devel] How framerate is passing to rtsp client

2016-03-31 Thread Ross Finlayson
> I am using testOnDemandRTSPServer example code from live555. I have wrote my > implementation of DeviceSource class. I have set presentation time properly: > > gettimeofday(&fPresentationTime, NULL); > fDurationInMicroseconds = 110; That’s your problem. You’re telling the server to wait 1

[Live-devel] How framerate is passing to rtsp client

2016-03-31 Thread Paweł Domagalski
Hi all,* * *Problem:* In my case, bit stream coming from h264 encoder which is feed by live camera. Bitstream is sending by live555 library using RTSP protocol. RTSP packets are received by one of rtsp client like vlc player( the most important), totem player, mplayer. I need to know how to s