[libcamera-devel] [PATCH 04/15] android: camera_stream: Construct with Android stream

Laurent Pinchart laurent.pinchart at ideasonboard.com
Wed Oct 7 15:37:38 CEST 2020


Hi Kieran,

On Wed, Oct 07, 2020 at 09:47:33AM +0100, Kieran Bingham wrote:
> On 07/10/2020 01:57, Laurent Pinchart wrote:
> > Hello,
> 
> <snip>:
> 
> >>>> I haven't gone to check yet, but I wonder if there is a better boolean
> >>>> logic to check ...
> >>>>
> >>>> 		if (format != NV12) perhaps ?
> >>>
> >>> We can't bet to have only NV12 and MJPEG
> >>
> >> No, indeed - my premise was that we will (later) need to make the
> >> decision somewhere about what a software stream is.
> >>
> >> I.e. - if the Android stream is an NV12, and we can only generate a
> >> YUYV, we will need a software(or opengl :D) format convertor (to support
> >> UVC).
> >>
> >> So there is going to be a more complex requirement here to decide what a
> >> software stream is, which will really be
> > 
> > Should we start calling them post-processed streams (we can bikeshed the
> > name), as the post-processing may be handled by hardware (hardware
> > scaler or format converter, JPEG encoder, GPU, ...) ?
> 
> Yes, indeed - we shouldn't be calling them software streams at all.
> 
> >>    "input format != output format"...
> >>
> >> Anyway, this is fine for now.
> >>
> >> The internal buffer handling will in fact make it much easier to look at
> >> software format conversion anyway.
> 
> <snip>
> 
> >>>>> -	CameraStream(libcamera::PixelFormat format, libcamera::Size size,
> >>>>> +	CameraStream(CameraDevice *cameraDev,
> >>>>
> >>>> I would have just used 'dev', or 'device', I don't think it conflicts
> >>>> with anything else in this function does it ?
> >>>>
> >>>> or as the class private member it goes into is cameraDevice_, it could
> >>>> have been cameraDevice ;-) - But it's not important either.
> >>>
> >>> I thought about shortening the name too, but as it goes to
> >>> cameraDevice_ I kept it long.
> >>>
> >>> And as Laurent said, if we could unify the naming schemes (ie.
> >>> everything android prefixed with camera3 and everything libcamera
> >>> prefixed with.... ) it would be nice
> > 
> > We could also use hal as a prefix for the android side to keep it
> > shorter.
> 
> And keep libcamera objects without a prefix? Or lc ?

I'd go for no prefix, lc sounds really weird (but maybe I'd get use to
it).

> >>>> Reviewed-by: Kieran Bingham <kieran.bingham at ideasonboard.com>

-- 
Regards,

Laurent Pinchart


More information about the libcamera-devel mailing list