[FFmpeg-devel] [PATCH] doc/examples/muxing: make compatible with C++
anshul
anshul.ffmpeg at gmail.com
Thu Mar 20 11:48:11 CET 2014
On 03/20/2014 04:12 PM, Stefano Sabatini wrote:
> On date Wednesday 2014-03-19 19:21:36 +0530, Anshul encoded:
>>
>> Michael Niedermayer <michaelni at gmx.at> wrote:
> [...]
>>> so to summarize we have
>>>
>>> A. add ~6 lines of code to each example to make it C++ compatible
>>> B. add seperate C++ examples
>>> C. add patches that get applied by makefile to create c++ examples
>>> D. add a description to the wiki/faq/whatever on how to make the
>>> examples C++ compatible
>>>
>>> Iam happy with any solution if theres a consensus, that is if the
>>> people in this thread, including Anshul agree.
>>>
>>> In absence of a consensus, anyone can volunteer to maintain C++
>>> examples and its then his/her decission on how to maintain them,
>>> that is in git as seperate files or on the wiki or as patches.
>>>
>>> I think its better if a consensus is found though, but i dont know
>>> if thats possible, peoples oppinion seem far appart
>>>
>>> [...]
>> I agree with B, in that way we can add example in most other language.
>> It would be easy to write an seprate example for python, php or gimp
>> scripts. Rather option A and C does not look possible for python and
>> PHP.
> How do you plan to add examples for python/php/gimp? As far as I know,
> we don't support those languages directly.
>
If may guys agrees with other language i can start sending python
examples using ctype.It take time so i would not start if no one is
interested.
I don't have much experience with php and gimp but i have seen
them using c library.
>> Option D is good for maintenance prospect's but user are more happy
>> with example. I think thats why linux developer's add examples with
>> most trivial system call.
>>
>> I am happy to maintain those examples.
> I'm for option D. Users will have to adapt the examples to their own
> environment, also documenting the required conversions will be useful.
> Providing a C++ example using a C++ toolkit seems a good option.
>
> I don't think maintaining duplicated code for C/C++ is a good idea as
> I don't want to keep in synch C and C++ code, maintaining C examples
> alone is enough work already, and we will end up with unsynched code
> (C and C++ versions working differently).
>
> Option A could be also be acceptable, but in the end we will need to
> add more than 6 lines (for example for supporting C constructs not
> supported in C++), and that will increase examples complexity even
> more.
More information about the ffmpeg-devel
mailing list