[Ffmpeg-devel] refactoring ffmpeg.c for shared librarycompatibility. (c++ cpp stream protocol)

Jaime V. inf220
Sun Dec 17 18:03:36 CET 2006


M?ns Rullg?rd wrote:
>>>> I'd like to refactorize ffmpeg.c in order to write a function to
>>>> initialize and teardown variables in it and need some help for it.
>>> exec("ffmpeg(.exe)", ...)
>> There two advantages on this proposal:
>> a) Spawning processes is slower that using this high level library,
> I can't imagine a situation where that overhead would be significant
> at all.

Well overhead comes from different factors.
The processing speed remains the same, but my suggestion allows for more 
flexibility towards the API user:

-Calling the executable does not allow for other protocols than the 
preinstalled ones.
-Maybe the caller has already opened a file. Saving to HD and 
recollecting the result causes some overhead both in time(small but 
present) as well as in programing and development effort.
-Using an executable, which on error just exit()'s does not allow for 
proper error messages to its calling host(well at least im not so 
proficient at std redirection yet. Hence my proposal of switching to int 
return values). Maybe even the error printfs could be handled a bit 
differently...in a not so near future.
-Maybe ffmpeg is being used in an obscure hardware environment where a 
custom protocol is needed.(player, embedded microoven, washing machine ;))
-The API is quite simplified for trivial tasks by using the already 
familiar ffmpeg.c syntax. Changing one command line is also easier to 
correct on a version change, than messing with all the scattered code 
lines if all we need is a simple image extraction or video/audio 
transcoding.

The attached stream protocol is what led me to this idea(still some 
dirty code but  here it goes).
I wrote it to handle already open c++ streams within ffmpeg.
Sorry for changing the subject line.
I did it so the files get found easier if anybody needs them.

They are basically a cheap implementation of storing the stream pointer 
adress in a char and retrieving it later within the protocol.
Things like this unfortunately do not work calling the exec.

J.
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: cppffstream.h
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20061218/52a5b5be/attachment.txt>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: cppffstream.cpp
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20061218/52a5b5be/attachment.asc>



More information about the ffmpeg-devel mailing list