0

I've done lots of searching but can't get quite enough info on how this really all come together.

So I understand that H264 frames contain some SPS and PPS info on the frames that you can extract frame rate from. But the PTS is actually coded in the PES? So how is PES transported in RTMP?

I'm using librtmp and a RTMPServer to push h264 frames. Does the server simply send the same packets to the clients that I send using librtmp? And RTMP has its own timestamp and framerate it seems in the packets it sends. So does RTMP client not need to extract framerate from h264 frames, etc and just rely on the RTMP packet data?

It'd be cool if anyone can explain how this all works together. And I am eventually trying to send useful timing info that can be parsed on the client side for absolute times.

TurtleTread
  • 1,297
  • 2
  • 12
  • 23

1 Answers1

1

Rtmp uses FLV to send the data. FLV has a 32 bit (technically it’s 24+8) field to set the DTS. It then has a separate fields to set the CTS, CTS = PTS - DTS.

szatmary
  • 29,969
  • 8
  • 44
  • 57
  • well im pretty lost tbh. could you point me to some resources I can read about this? How is the pts related to rtmp timstamps in the headers? and the pts syncing for audio and video uses the pts in the pes rather than the rtmp timestamp? – TurtleTread Dec 11 '19 at 07:42
  • 1
    PTS is the timestamp. There is no PES in rtmp. only mpegts has a PES. RTMP uses FLV. – szatmary Dec 11 '19 at 07:48
  • Ok I'm reading the spec doc. It seems that's all in the chunk header. FLV specifies that first tag is always has timestamp 0. So that's why I sent the stream with librtmp. But how does rtmpserver send the info to the client? The client can connect at any time, does the server need to recalculate all the timestamps and start at 0? This means we can't really code in an absolute time in the stream, but rather rely on time sync on the client-server handshake time? – TurtleTread Dec 11 '19 at 10:42
  • 1
    No. The stream should start at zero so when a client connects it knows how much time has passed since the start of the stream. You can put in any start value you want, the player will just think the stream was longer that it really was. – szatmary Dec 11 '19 at 15:43
  • Hi, thank you for your answers. This clarified stuff for me. Now I'd like to ask you how to handle timestamps. Do we have to wrap time after it reaches 2^32-1? Like we can't just reset to 0 whenever? – TurtleTread Dec 16 '19 at 07:15
  • Yes, timestamps can wrap around. – szatmary Dec 16 '19 at 07:21
  • How is time mapping done generally? I'd like to track the actual time. Can I send a reconnect signal to the client every period of time and reset to zero? Otherwise, I'd have to track the initial connect time and wait for the end of 32 bit time? – TurtleTread Dec 16 '19 at 08:11
  • Generally people don’t streams (let alone tcp sessions) that last almost 2 months. And if they do, they don’t use rtmp. – szatmary Dec 16 '19 at 15:31
  • So does a client implementation ever use RTMP message timestamp for calculating passed time for example? And you said I can pass in any start value for flv tag timestamp? but the specification says the first tag must be zero though. – TurtleTread Dec 26 '19 at 09:57
  • No. using time stamps as a a clock will certainly cause problems. The specification of RTMP is famously poor. All RTMP server I know will not reject a stream if it doesn’t begin at zero. In fact the most expensive RTMP client I know doesn’t start at zero. – szatmary Dec 26 '19 at 11:53
  • Well I'm talking about the flv's first tag timestamp has to be 0. It's specified in the doc. – TurtleTread Dec 27 '19 at 05:20
  • 1
    I’m talking about the same thing. What I am telling you is that doc was written after may implementations we’re developed through reverse engineering. And most servers doesn’t care. – szatmary Dec 27 '19 at 18:15
  • hey @szatmary I have posted a new question regarding flv in rtmp. Could you can take a look and try to answer it? https://stackoverflow.com/questions/59642889/how-is-flv-format-contained-in-rtmp – TurtleTread Jan 08 '20 at 09:30