[FFmpeg-devel] [PATCH] libavdevice: v4l2: use libv4l2 when requested.

[Luca Abeni]

Hi M?ns,

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).


			Thanks,
				Luca