Paul B Mahol (2018-03-22):
> Why? OpenCV != OpenCL
Oh, I had not noticed. Good then.
Regards,
--
Nicolas George
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
On 3/22/18, Nicolas George wrote:
> Rostislav Pehlivanov (2018-03-20):
>> There was absolutely nothing in my sentence to imply I'm sarcastic, and I
>> make sure to be obviously sarcastic when I want to be.
>> The filter we have supports a very limited subset of the features of
>>
Rostislav Pehlivanov (2018-03-20):
> There was absolutely nothing in my sentence to imply I'm sarcastic, and I
> make sure to be obviously sarcastic when I want to be.
> The filter we have supports a very limited subset of the features of opencv
> and if there's no overlap we should probably write
On 20 March 2018 at 15:02, Nicolas George wrote:
> Rostislav Pehlivanov (2018-03-19):
> > Yeah, I agree, I don't think vf_opencv is very useful and we ought to
> drop
> > it.
>
> I cannot decide if you are being serious or sarcastic.
>
> Regards,
>
> --
> Nicolas George
>
>
tis 2018-03-20 klockan 16:28 +0100 skrev Tobias Rapp:
> On 20.03.2018 16:02, Nicolas George wrote:
> > Derek Buitenhuis (2018-03-19):
> > > If you want to link with a C++ library that is indeed the
> > > 'proper' solution.
> > > As far as I am aware "several languages all have that
> > >
On Tue, 20 Mar 2018 00:23:54 +0100
Carl Eugen Hoyos wrote:
> 2018-03-19 21:49 GMT+01:00, Derek Buitenhuis :
>
> > libutvideo was handled 100% incorrectly. We hardcoded
> > libstdc++ as a dependency
>
> Which worked fine on osx (and all other
On Mon, 19 Mar 2018 19:01:49 +0200
Jan Ekström wrote:
> On Mon, Mar 19, 2018 at 6:28 PM, wm4 wrote:
> > On Mon, 19 Mar 2018 09:35:22 -0400
> > Jeff Cook wrote:
> >
> >> Hello,
> >>
> >> Please see the bug report at
On 20.03.2018 16:02, Nicolas George wrote:
Derek Buitenhuis (2018-03-19):
If you want to link with a C++ library that is indeed the 'proper' solution.
As far as I am aware "several languages all have that requirement" is simply
a theoretical scenario that doesn't actually exist. What else
On 3/20/18, Nicolas George wrote:
> Rostislav Pehlivanov (2018-03-19):
>> Yeah, I agree, I don't think vf_opencv is very useful and we ought to
>> drop
>> it.
>
> I cannot decide if you are being serious or sarcastic.
It supports very few pixel formats.
Rostislav Pehlivanov (2018-03-19):
> Yeah, I agree, I don't think vf_opencv is very useful and we ought to drop
> it.
I cannot decide if you are being serious or sarcastic.
Regards,
--
Nicolas George
signature.asc
Description: Digital signature
Derek Buitenhuis (2018-03-19):
> If you want to link with a C++ library that is indeed the 'proper' solution.
> As far as I am aware "several languages all have that requirement" is simply
> a theoretical scenario that doesn't actually exist. What else beside C++
> requires this?
No, it is not a
Paul B Mahol (2018-03-20):
> Nobody cares.
Rude.
--
Nicolas George
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
On 3/20/18, Carl Eugen Hoyos wrote:
> 2018-03-19 21:49 GMT+01:00, Derek Buitenhuis :
>
>> libutvideo was handled 100% incorrectly. We hardcoded
>> libstdc++ as a dependency
>
> Which worked fine on osx (and all other systems that were
> ever
2018-03-19 21:49 GMT+01:00, Derek Buitenhuis :
> libutvideo was handled 100% incorrectly. We hardcoded
> libstdc++ as a dependency
Which worked fine on osx (and all other systems that were
ever tested).
More important imo is that Jeff forgot to attach his patch.
On 19 March 2018 at 20:57, Nicolas George wrote:
> Derek Buitenhuis (2018-03-19):
> > libutvideo was handled 100% incorrectly. We hardcoded libstdc++ as a
> > dependency, but the proper solution was to link with CXX instead of CC.
>
> This is not a *proper* solution, since it
On 3/19/2018 8:57 PM, Nicolas George wrote:
> Derek Buitenhuis (2018-03-19):
>> libutvideo was handled 100% incorrectly. We hardcoded libstdc++ as a
>> dependency, but the proper solution was to link with CXX instead of CC.
>
> This is not a *proper* solution, since it does not scale to the case
Derek Buitenhuis (2018-03-19):
> libutvideo was handled 100% incorrectly. We hardcoded libstdc++ as a
> dependency, but the proper solution was to link with CXX instead of CC.
This is not a *proper* solution, since it does not scale to the case
where several languages all have that requirement.
On 3/19/2018 5:01 PM, Jan Ekström wrote:
> On Mon, Mar 19, 2018 at 6:28 PM, wm4 wrote:
>> On Mon, 19 Mar 2018 09:35:22 -0400
>> Jeff Cook wrote:
>>
>>> Hello,
>>>
>>> Please see the bug report at https://github.com/opencv/opencv/issues/10963
On Mon, Mar 19, 2018 at 6:28 PM, wm4 wrote:
> On Mon, 19 Mar 2018 09:35:22 -0400
> Jeff Cook wrote:
>
>> Hello,
>>
>> Please see the bug report at https://github.com/opencv/opencv/issues/10963 ,
>> which discusses OpenCV's failure to build as
On Mon, 19 Mar 2018 09:35:22 -0400
Jeff Cook wrote:
> Hello,
>
> Please see the bug report at https://github.com/opencv/opencv/issues/10963 ,
> which discusses OpenCV's failure to build as pure C since upstream version
> 3.4.1, and also discusses how all modules
On Mon, 19 Mar 2018 09:35:22 -0400
Jeff Cook wrote:
> Hello,
>
> Please see the bug report at https://github.com/opencv/opencv/issues/10963 ,
> which discusses OpenCV's failure to build as pure C since upstream version
> 3.4.1, and also discusses how all modules
Hello,
Please see the bug report at https://github.com/opencv/opencv/issues/10963 ,
which discusses OpenCV's failure to build as pure C since upstream version
3.4.1, and also discusses how all modules that use OpenCV 2 or later should be
compiled as C++ to avoid esoteric issues and serious
22 matches
Mail list logo