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

Michael Niedermayer michaelni at gmx.at
Thu Mar 6 17:05:43 CET 2014


On Wed, Mar 05, 2014 at 10:18:23PM +0000, Martin Panter wrote:
> 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.

thanks and yes its important that these things are tested with ffmpeg


> 
> 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.
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Everything should be made as simple as possible, but not simpler.
-- Albert Einstein
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20140306/74bdcd72/attachment.asc>


More information about the ffmpeg-devel mailing list