[FFmpeg-devel] [PATCH] avformat/rtmppkt: handle extended timestamp field even for one-byte header

[Martin Panter]

Hi, it turns out this has been sent to the “libav” list, and there was
a mistake in the write function. When it gets fixed up over there, I
am happy to help test a version ported back here, however you folks
want to handle it.

On 5 March 2014 05:33, Martin Panter <vadmium+rtmp at gmail.com> wrote:
> Related fix in "rtmpdump":
> https://repo.or.cz/w/rtmpdump.git/commitdiff/79459a2
>
> Adobe's RTMP specification (21 Dec 2012), section 5.3.1.3 ("Extended
> Timestamp"), says "this field is present in Type 3 chunks". Type 3 chunks are
> those with the one-byte header size.
>
> This resolves intermittent hangs and segfaults caused by the read function,
> and also includes an untested fix for the write function.
>
> The read function was tested with ABC (Australia) News 24 streams, however
> they are probably restricted to only Australian internet addresses. Some of
> the packets at the start of these streams seem to contain junk timestamp
> fields, often requiring the extended field. Test command:
>
> ffplay rtmp://cp81899.live.edgefcs.net/live/news24-med@28772
> ---
> Original patch: https://github.com/vadmium/FFmpeg/commit/0a1e2be.patch
>
> I fixed the equivalent issue in “rtmpdump” and Martin Storsjö
> suggested fixing the internal “libavformat” implementation as well, so
> here you are :). I also tried fixing the packet write function,
> because it shares the affected “ts_delta” field, but I have not tested
> it. (Testing would probably involve generating packets with a
> timestamp delta ≥ 0xFFFFFF, or arbitrary junk like I was seeing from
> the ABC.)
>
> Also, I would suggest renaming “ts_delta” to “ts_field” or something
> in the RTMPPacket structure, because it is not always interpreted as a
> delta. But I’m not sure if that is practical; maybe the structure has
> a public API scope or is used elsewhere.