[rtmpdump] Future of rtmpdump/librtmp

[Kai Pastor, DG0YT]

Am 17.06.24 um 22:58 schrieb Howard Chu:
>> Will there be an official release 2.6 (preferably in the form of a tarball)?
> Maybe. We haven't done tarballs in quite a long time. A git tag would be more likely.

As far as vcpkg is concerned: it will use asset caching for tarballs, 
but not for git.

(librtmp won't be used in every build, but calling git isn't the 
preferred form to get official sources.)

>> What is the recommendation on the proliferation of usage of librtmp/rtmpdump:
>>   - accept new downstream references (such as adding an rtmp feature to the curl port in vcpkg),
> curl support of librtmp has been around for many years already.
I'm aware of that. This capability is the driver for (others) touching 
vcpkg port librtmp now and possibly making the capability available now. 
I wonder if it is worth the ongoing maintenance burden in vcpkg - in 
particular if it isn't actually used or tested by the contributors who 
touch these ports now.
>> - freeze the current status, or
>> - actively delist it from registries (like vcpkg)?
> The statement "nobody should be using this any more" is about RTMP itself.
>
> Adobe officially killed Flash, as of December 31, 2020.
>
> https://www.howtogeek.com/700229/adobe-flash-is-deadheres-what-that-means/
>
> Flash was the only official client for RTMP. With that gone, there's no reason for anybody to
> be using an RTMP server any more, and thus no reason for anyone to be using librtmp in any
> clients any more.

Thanks.
Kai Pastor

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.mplayerhq.hu/pipermail/rtmpdump/attachments/20240618/2e06ba57/attachment.htm>