> Hard-coded URL parameters, >nothing to set the formats, not even the possibility of a filter that >changes the resolution.
This filter has options: url and content-type header for requests and it's not hardcoded. Format and resolution can be changed after this filter later in filter graph, it's not a job for this filter, for example: ffmpeg -i video.mp4 -vf scale=1920:-1,format=rgb24,http=url="http://localhost:3000/frame?type=ffmpeg":content_type="application/octet-stream",scale=1280:-1,format=yuv420p -c:v h264 -y out.mp4 And it will be send raw frames to servers with additional parameters in url query, like that: "POST http://localhost:3000/frame?type=ffmpeg&width=1280&height=720&format=2&linesize=344336064&size=2764800&pts=22012 For my opportunity this filter open door for postprocess frames outside of ffmpeg, so filter can be written or at least prototyped in other languages: js, python, go, etc without touching ffmpeg code and quick start for people who don't know c language or may be script is to big for porting to ffmpeg code. For my use case I will be used it to "connect" ffmpeg to python (this script is huge and complicated to porting to c language and ffmpeg) script that postprocess frame/image in different process (docker container). Without this http filter I must do the same stuff in multiple steps, for example (it's typical usage): #1 use ffmpeg to extract jpg's images for every frame from video and save it to folder on disk #2 run custom python script on every images in folder and create output images #3 use ffmpeg to marge images into video and do something to sink movie But instead of multistage flow I can convert video in single step with injection of "http" filter in filter graph like in example. --- Original message --- From: "Nicolas George" <geo...@nsup.org> Date: 11 September 2020, 12:40:23 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 _______________________________________________ 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".