Timo Rothenpieler (12020-09-11): > Entirely outside of this filter being acceptable at all, > pulling in libcurl is not an option without major safeguards for every > single overlapping tls library both ffmpeg and curl support. > If both are using the same library, there is a huge potential for libcurl > being linked at all breaks ffmpegs ability to talk TLS. > > On top of that, ffmpeg already has code to talk to http servers, so pulling > in a library to do it is even less acceptable.
I completely agree with this. > I also really fail to see the utility of this filter. What's stopping you > from just making ffmpeg output raw frames and then sending them off via the > curl cli tool or whatever else? This would happen at the end of the filter graph. This patch is for something in the middle. For a complex graph, I do not think there is an easy way of implementing with just command-line tools. We would need some kind of movie sink for that. But this is way too specific to be accepted. Hard-coded URL parameters, nothing to set the formats, not even the possibility of a filter that changes the resolution. This is exactly what I was warning about in this mail: https://ffmpeg.org/pipermail/ffmpeg-devel/2020-September/269348.html And do not let us forget that the coding style is not at all what we do. Regards, -- Nicolas George
signature.asc
Description: PGP signature
_______________________________________________ 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".
