Re: Zero-copy CameraFile transfer?
Alan Corey <[email protected]> Fri, 11 Mar 2022 08:44:03 -0500
| Newsgroups | gmane.comp.multimedia.gphoto.user |
|---|---|
| Message-ID | <CAOh3dDaaBUaD7hxAHb_GMX7pju1kdU+RA1XdrpqGkPe6eYUs+w@mail.gmail.com> |
--===============6581786552889313091== Content-Type: multipart/alternative; boundary="000000000000ec2e6305d9f18612" --000000000000ec2e6305d9f18612 Content-Type: text/plain; charset="UTF-8" Looks fun, see the sendfile man page. On Fri, Mar 11, 2022 at 3:10 AM Marcus Meissner <[email protected]> wrote: > Hi, > > No, this works both ways. > > You can download files into a filedescriptor / handler or memory, > or upload. > > But both use some buffering. As far as I see libusb with its urb model > is not directly doing filedescriptor passing, so there will always be > a bit of buffers involved. > > Ciao, Marcus > > On Thu, Mar 10, 2022 at 09:36:09AM -0800, Dave Taylor wrote: > > That would work for transferring a file to the camera, right? I'm > > more concerned about transferring a file from the camera. > > > > =-ddt-> > > > > On Wed, Mar 9, 2022 at 11:32 PM Marcus Meissner <[email protected]> > wrote: > > > > > > On Wed, Mar 09, 2022 at 07:02:40PM -0800, Dave Taylor wrote: > > > > Hi, I've been looking through the libgphoto2 API for a way to > > > > implement zero-copy transfers such as through Linux's sendfile(2) > > > > system call, but it seems there isn't currently an exposed way to get > > > > at an open CameraFile's file descriptor to pull this off. > > > > > > > > I do see that the CameraFile object has an fd member in it that > > > > gp_file_slurp() references, but the comments say that gp_file_slurp() > > > > is an internal function and that gp_file_open() is now deprecated. > > > > > > > > Is there a cleaner way to do this? Or should I not play with > matches? :) > > > > > > If you create a CameraFile from a fd or a handler (gp_file_new_from_fd > / > > > gp_file_new_from_handler), it will only use a small local buffer > (currently 512kb) > > > to transfer data. > > > > > > gp_file_new() itself would use in-memory storage for the full image. > > > > > > I can take a look to avoid any kind of buffering, not sure if libusb1 > allows this. > > > > > > Ciao, Marcus > > > > > > _______________________________________________ > > Gphoto-user mailing list > > [email protected] > > https://lists.sourceforge.net/lists/listinfo/gphoto-user > > > _______________________________________________ > Gphoto-user mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/gphoto-user > -- ------------- Education is contagious. --000000000000ec2e6305d9f18612 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">Looks fun, see the sendfile man page.<br></div><br><div cl= ass=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Fri, Mar 11, 2= 022 at 3:10 AM Marcus Meissner <<a href=3D"mailto:[email protected]">meis= [email protected]</a>> wrote:<br></div><blockquote class=3D"gmail_quote" styl= e=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);paddin= g-left:1ex">Hi,<br> <br> No, this works both ways.<br> <br> You can download files into a filedescriptor / handler or memory,<br> or upload.<br> <br> But both use some buffering. As far as I see libusb with its urb model<br> is not directly doing filedescriptor passing, so there will always be<br> a bit of buffers involved.<br> <br> Ciao, Marcus<br> <br> On Thu, Mar 10, 2022 at 09:36:09AM -0800, Dave Taylor wrote:<br> > That would work for transferring a file to the camera, right?=C2=A0 I&= #39;m<br> > more concerned about transferring a file from the camera.<br> > <br> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=3D-ddt-><br> > <br> > On Wed, Mar 9, 2022 at 11:32 PM Marcus Meissner <<a href=3D"mailto:= [email protected]" target=3D"_blank">[email protected]</a>> wrot= e:<br> > ><br> > > On Wed, Mar 09, 2022 at 07:02:40PM -0800, Dave Taylor wrote:<br> > > > Hi, I've been looking through the libgphoto2 API for a w= ay to<br> > > > implement zero-copy transfers such as through Linux's se= ndfile(2)<br> > > > system call, but it seems there isn't currently an expos= ed way to get<br> > > > at an open CameraFile's file descriptor to pull this off= .<br> > > ><br> > > > I do see that the CameraFile object has an fd member in it t= hat<br> > > > gp_file_slurp() references, but the comments say that gp_fil= e_slurp()<br> > > > is an internal function and that gp_file_open() is now depre= cated.<br> > > ><br> > > > Is there a cleaner way to do this?=C2=A0 Or should I not pla= y with matches?=C2=A0 :)<br> > ><br> > > If you create a CameraFile from a fd or a handler (gp_file_new_fr= om_fd /<br> > > gp_file_new_from_handler), it will only use a small local buffer = (currently 512kb)<br> > > to transfer data.<br> > ><br> > > gp_file_new() itself would use in-memory storage for the full ima= ge.<br> > ><br> > > I can take a look to avoid any kind of buffering, not sure if lib= usb1 allows this.<br> > ><br> > > Ciao, Marcus<br> > <br> > <br> > _______________________________________________<br> > Gphoto-user mailing list<br> > <a href=3D"mailto:[email protected]" target=3D"_blank"= >[email protected]</a><br> > <a href=3D"https://lists.sourceforge.net/lists/listinfo/gphoto-user" r= el=3D"noreferrer" target=3D"_blank">https://lists.sourceforge.net/lists/lis= tinfo/gphoto-user</a><br> <br> <br> _______________________________________________<br> Gphoto-user mailing list<br> <a href=3D"mailto:[email protected]" target=3D"_blank">Gpho= [email protected]</a><br> <a href=3D"https://lists.sourceforge.net/lists/listinfo/gphoto-user" rel=3D= "noreferrer" target=3D"_blank">https://lists.sourceforge.net/lists/listinfo= /gphoto-user</a><br> </blockquote></div><br clear=3D"all"><br>-- <br><div dir=3D"ltr" class=3D"g= mail_signature">-------------<br>Education is contagious.<br><br><br><br><b= r><br><br></div> --000000000000ec2e6305d9f18612-- --===============6581786552889313091== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline --===============6581786552889313091== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Gphoto-user mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/gphoto-user --===============6581786552889313091==--