Fixed parsing of extended timestamp in chunk message header type 3

[jbreich]

It appears that extended timestamps can be used in chunk message header type 3 if it was used in preceding non type 3 chunk. This is defined in RTMP specification in Extended Timestamp section:

This field is present in Type 3 chunks when the most recent Type 0,
1, or 2 chunk for the same chunk stream ID indicated the presence of
an extended timestamp field.

You can reproduce the problem using ffmpeg by adding a filter to modify the first PTS to a huge value forcing to use a high timestampDelta: ffmpeg -re -i ${YOUR_INPUT_FILE} -vf "setpts=PTS+20000/TB" -af "asetpts=PTS+20000/TB" ... your encoding options... -f flv ${YOUR_RTMP_SERVER}
This adds 20000 seconds to the first PTS which is greater than what a non-extended timestamp can support (at most 16777214 milliseconds)

[dustinlindquist]

I've tested this by sending rtmp mostly comprised of type 0 chunks with type 3 chunks following and can confirm that this fixes streams that are longer than 16777215ms (~4.66 hours). Previously it was panicking with Server closed by error: Err = Panic: invalid state in the examples/server_relay_demo.