I don't think so. The existing 'strict' option is more general and touches lots of things in encoding/decoding. The new option is very narrow in scope. The existing 'strict' and the new 'rtmp_strict_paths` don't have anything to do with each other - in fact it would be quite possible that a user might want one off and the other on.
On Wed, Sep 25, 2019 at 3:14 PM Carl Eugen Hoyos <ceffm...@gmail.com> wrote: > Am Mi., 25. Sept. 2019 um 21:04 Uhr schrieb William Martin > <unique.will.mar...@gmail.com>: > > > > From: Will Martin <will.mar...@verizondigitalmedia.com> > > > > Motivation: When running multiple rtmp ingest on the same machine on the > same port, users may want to explicitly forbid mismatched rtmp streams from > successfully completing handshakes. This patch allows for such enforcement > > There already is a "strict" option, can't it be used here instead > of adding a new option? > > Carl Eugen > _______________________________________________ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
