Skip to content

rtmp: proper handling of extended timestamps (take 2) #184

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 4 commits into from
Feb 1, 2019

Conversation

alfredh
Copy link
Contributor

@alfredh alfredh commented Jan 30, 2019

draft, needs more testing...

@alfredh
Copy link
Contributor Author

alfredh commented Jan 31, 2019

@alfredh
Copy link
Contributor Author

alfredh commented Jan 31, 2019

when type 3 is used for fragmented packets, the extended timestamp is duplicated
from the previous type 0 or type 1/2 packet. this is redundant information.
from testing with ffmpeg, it looks like this value is ignored.

when receiving a single type 3 packet (no fragmentation) the header info should
be copied from the previous type 0 or 1/2 packet. in this case the extended timestamp
should be read and used.

	case 3:
		if (!chunk->mb) {

			chunk->mb = mbuf_alloc(chunk->hdr.length);
			if (!chunk->mb)
				return ENOMEM;

			if (chunk->hdr.format == 0) {
				chunk->hdr.timestamp_delta =
					chunk->hdr.timestamp;
			}

			chunk->hdr.timestamp += chunk->hdr.timestamp_delta;
		}

		if (chunk->hdr.ext_ts) {

			uint32_t ext_ts;

			if (mbuf_get_left(mb) < 4)
				return ENODATA;

			ext_ts = ntohl(mbuf_read_u32(mb));

			if (chunk->hdr.format == 0)
				chunk->hdr.timestamp = ext_ts;
			else
				chunk->hdr.timestamp_delta = ext_ts;
		}

@alfredh
Copy link
Contributor Author

alfredh commented Jan 31, 2019

I did some more testing with ffmpeg.

I made a hack in libre, where the extended timestamp is not added
for type 3 (this is a protocol error).

in this case ffmpeg gave lots of warnings and closed the connection:

[rtmp @ 0x7fd970d1f4c0] Too short chunk size change packet (0)
[flv @ 0x7fd97180a600] Packet mismatch 511311794 11 600366
[tcp @ 0x7fd970c0cc00] RTMP packet size mismatch 2046522 != 10293543
[tcp @ 0x7fd970c0cc00] RTMP packet size mismatch 8481913 != 6367078
[tcp @ 0x7fd970c0cc00] RTMP packet size mismatch 3870470 != 6192111
[tcp @ 0x7fd970c0cc00] RTMP packet size mismatch 10199958 != 5529381
frame=  248 fps= 24 q=28.0 size=     256kB time=00:00:10.51 bitrate= 199.4kbits/s dup=1 drop=0 speed=1.02x   [tcp @ 0x7fd970c0cc00] RTMP packet size mismatch 9836232 != 11058686
[tcp @ 0x7fd970c0cc00] RTMP packet size mismatch 16612785 != 10903604
[tcp @ 0x7fd970c0cc00] RTMP packet size mismatch 14281432 != 14340103
[tcp @ 0x7fd970c0cc00] RTMP packet size mismatch 8113144 != 9933097
[tcp @ 0x7fd970c0cc00] RTMP packet size mismatch 6357270 != 13125711
[tcp @ 0x7fd970c0cc00] RTMP packet size mismatch 10539962 != 2336863
[tcp @ 0x7fd970c0cc00] RTMP packet size mismatch 4674907 != 8470418
[tcp @ 0x7fd970c0cc00] RTMP packet size mismatch 10346371 != 15941361

The ffmpeg command used was:

$ ffmpeg -y -loglevel info -listen 1 -i rtmp://127.0.0.1:1935 out.mp4

@richaas richaas merged commit db30ce1 into master Feb 1, 2019
@richaas richaas deleted the rtmp_extended_timestamp2 branch February 1, 2019 10:21
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants