[FFmpeg-devel] [PATCH] libavdevice: v4l2: use libv4l2 when requested.
Thu May 13 22:39:49 CEST 2010
On 13/05/10 22:25, M?ns Rullg?rd wrote:
>> As far as I can see, this libv4l dependency is optional (if the
>> library is not installed, we can still compile the good old code). So,
>> I think this should not be a problem...
> I am fundamentally opposed to using that library at all. Period.
Ok. So, we disagree on this :)
I think that libv4l can be a reasonable solution for using those webcams
until the correct solution is implemented (especially because this patch
is not intrusive, and in my opinion it does not create any harm), but if
some major developers are against it I'll not commit the patch.
I'll just try to use the rest of this email to convince you...
> It is doing decoding/conversion in a _demuxer_ context, which is at
> odds with FFmpeg design principles.
I agree with this. I have no points here.
> What's more, it does this by means of a shoddy external library.
But support for this library is optional, so I do not see a big problem here
> Worse still, the patch is a hack.
I am not convinced about this (I am not talking about the configure
part). The v4l2.c part of the patch is small, unintrusive, and it cannot
(IMHO) create problems. And it solves a big problems for some people.
(again, I know that performing the conversion here is not a good idea,
but this - libv4l - is what we have right now, with almost 0 effort. The
correct solution can be implemented later, but in the meanwhile people
will have something working...)
>> I agree that the correct solution would be to add support for bayer
>> (or whatever it is) in libswscale or libavcodec, and if/when I get a
>> webcam which requires it I'll implement the right thing.
> Wouldn't a sample capture be enough? Or did you mean you'll implement
> when you need it yourself?
The second one :)
>> But for now there are people who seem to want to use libv4l (and do
>> not want to use LD_PRELOAD, for some reason...). Since the patch is
>> not intrusive, I think it can be ok (modulo the fact that someone has
>> to review the configure part). No?
> Then the configure part is rejected. It uses pkg-config. I didn't
> check for other issues.
Ok, that's fair. But if the pkg-config part is fixed, can the configure
part be accepted? (Just asking to avoid useless work to Konstantin).
More information about the ffmpeg-devel