[AkBKukU]

I have a project that uses a proprietary SDK for decoding raw video. I output the decoded data as pure RGBA in a way FFMpeg can read through a pipe to re-encode the video to a standard codec. FFMpeg can't include the Non-Free SDK in their source, and it would be wildly impracticable to store the pure RGBA in a file. So pipes are the only way to do it, there are valid reasons to use high throughput pipes.

[ploxiln]

What percentage of CPU time is used by the pipe in this scenario? If pipes were 10x faster, would you really notice any difference in wall-clock-time or overall-cpu-usage, while this decoding SDK is generating the raw data and ffmpeg is processing it? Are these video processing steps anywhere near memory copy speeds?

[CyberDildonics]

So pipes are the only way to do it

Lets not get carried away. You can use ffmpeg as a library and encode buffers in a few dozen lines of C++.

[quietbritishjim]

The parent comment mentioned license incompatibility, which I guess would still apply if they used ffmpeg as a library.

[whiterknight]

And you go from having a well defined modular interface that’s flexible at runtime to a binary dependency.

[Almondsetat]

ffmpeg's library is notorious for being a complete and utter mess

[whartung]

What about domain sockets?

It's clumsier, to be sure, but if performance is your goal, the socket should be faster.

[AkBKukU]

It looks like FFmpeg does support reading from sockets natively[1], I didn't know that. That might be a better solution in this case, I'll have to look into some C code for writing my output to a socket to try that some time.

[1] https://ffmpeg.org/ffmpeg-protocols.html#unix

[ptx]

Why should sockets be faster?

[jcelerier]

Why not just store the output of the proprietary codec in an AVFrame that you'd pass to libavcodec in your own code?

[Sesse__]

At some point, I had a similar issue (though not related to licensing), and it turned out it was faster to do a high-bitrate H.264-encode of the stream before sending it over the FFmpeg socket than sending the raw RGBA data, even over localhost… (There was some minimal quality loss, of course, but it was completely irrelevant in the big picture.)

[jraph]

> There was some minimal quality loss, of course, but it was completely irrelevant in the big picture

But then the solutions are not comparable anymore, are they? Would a lossless codec instead have improved speed?