[rtmpdump] librtmp extend timestamp can't accept by FMS3.5/red5/crtmpserver ?

Martin Panter vadmium+rtmp at gmail.com
Mon Oct 21 13:03:28 CEST 2013


On 21 October 2013 07:32, VGAIC畅通-邱工 <gongfen at vgaic.com> wrote:
> Dear Sir,
>
> I use librtmp to send rtmp packet to rtmp server(FMS3.5/red5/crtmpserver).
> The librtmp version is git from server(Mon Sep 23 22:45:29 2013 +0300).
> After I use librtmp to send 4.5 hours(time stampe is large 0xffffff), then
> rtmp server will send "Netstream.unpublish.success". And I see the server
> log and found that librtmp's packet is can't accept.
>
> My app is rtmp live stream and the timestamp is from 0 40 80... to 0xffffff
> and forerver, but then I can only use 4.5 hours and again to connect the
> server.
> And I use this config to send h264 frame to the server:
>         vpacket.m_hasAbsTimestamp = TRUE;
>         vpacket.m_packetType = RTMP_PACKET_TYPE_VIDEO;
>         vpacket.m_nChannel = 0x03;
>         vpacket.m_headerType = RTMP_PACKET_SIZE_LARGE;
>         vpacket.m_nTimeStamp = nTimeStamp;
>         vpacket.m_nInfoField2 = rtmp->m_stream_id;
>         vpacket.m_nBodySize = i + size;
>
> So, there is anyone to help me about this problem? Thanks.

I recently had an issue that was caused by extended timestamps (those
over 0xFFFFFF) in certain kinds of packets, but it was with “rtmpdump”
and in an RTMP_ReadPacket() function. It sounds like your problem is
with constructing and sending packets in the other direction, so my
patch might not directly solve your problem. But since there is a bug
reading packets I wouldn’t be too surprised if there is an equivalent
bug writing packets.

My patch to fix the bug for reading packets:
https://lists.mplayerhq.hu/pipermail/rtmpdump/2013-September/002316.html


More information about the rtmpdump mailing list