[rtmpdump] [PATCH] Extended timestamp field may be present in type 3 chunk headers

[Martin Panter]

On 2 March 2014 18:26, Martin Storsjö <martin at martin.st> wrote:
>> Hello, there does not seem to be a whole lot going on in this mailing
>> list. A few months ago I sent this patch to fix a bug, and I haven’t
>> seen any action, so I am trying again.
>
>
> This has been applied now.

Thank you very much.

> I wasn't able to test it myself though, I get "[ AccessManager.Reject ] :
> Connection Geoblocked" when I try to access it. What country should the
> stream be available in - or is there any other more up to date stream that I
> could test?

The stream I referred to must be limited to Australia only:

rtmpdump -r rtmp://cp81899.live.edgefcs.net/live/news24-med@28772 --live

Unfortunately the only streams I have encountered exposing this
timestamp issue are the ABC’s (Australia) and probably all geoblocked.

> I'd like to make sure this is fixed in the libavformat rtmp implementation
> as well, but it's pretty hard to do so without a stream to test. Or are you
> able to implement it for libavformat as well?

Looks like the relevant function may be rtmp_packet_read_one_chunk()
in libavformat/rtmppkt.c. When I get a chance I’ll see if I can
reproduce the problem and test it, though I’m curious why FF MPEG and
“libav” both have the different internal and external RTMP
implementations. I assume you have to use different build or run time
options to exercise the internal code. (My “ffmpeg” command currently
shows “--enable-librtmp”, and I got MPV playing RTMP properly without
this timestamp issue by getting it to use a modified librtmp.1.so
without changing the FF MPGE libraries.)