[rtmpdump] [PATCH] Extended timestamp field may be present in type 3 chunk headers
vadmium+rtmp at gmail.com
Mon Mar 3 01:10:33 CET 2014
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.)
More information about the rtmpdump