[FFmpeg-devel] [PATCH] avfilter: add http video filter.

[Alex]

> 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" <george at 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 at ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request at ffmpeg.org with subject "unsubscribe".