Re: Video capture on EOS 650d only with 4 to 8 fps?

On Sat, Dec 26, 2020 at 11:32:02AM +0100, Thomas Orgis wrote:
> Am Thu, 24 Dec 2020 16:02:59 +0100
> schrieb Marcus Meissner <[email protected]>: 
> 
> > > Perhaps video was smoother with some ancient version of the code and
> > > this is all a regression?  
> > 
> > What you can do:
> > 
> > 	gphoto2 --capture-movie=1s --debug --debug-logfile=1second.og
> > 
> > and upload it somewhere? Then I can see where delays happen.
> 
> I did something similar when I checked a fresh local build before …
> 
> > You can also try the attached patch against current GIT...
> > 
> > This removes the backoff waiting logic in the preview code.
> 
> … and I also stumbled over this line and tried what happens when just
> not waiting there;-) It did not improve things.
> 
> I inserted some timings in camera_capture_preview() to produce the
> attached minimal timing log and it seems that, while some
> improvement might be possible, the camera won't ever deliver smooth
> video via that method.
> 
> An example of what I got:
> 
> lead-up ms 0 0 0 0 0 0 22
> event poll 4 100
> cap took 128 ms
> lead-up ms 0 0 0 0 0 0 3
> event poll 9 95
> cap took 104 ms
> lead-up ms 0 0 0 0 0 0 9
> event poll 2 85
> cap took 100 ms
> 
> 
> That means. 22 down to 3 ms in the function before entering the
> get_viewfinder loop. Then, 2 to 9 ms in ptp_check_eos_events() and then
> accumulating to 85 to 100 ms for ptp_canon_eos_get_viewfinder_image().
> 
> These examples where without entering the branch with the
> waiting_for_timeout() (where the actual waiting is disabled) at all.
> 
> There is quite some variation, but the meat really seems to be in the
> viewfinder image extraction itself, not some busywork and delays around
> it. 100 ms in that function won't ever give me 25 fps:-(
> 
> So it's down to this:
> 
> uint16_t
> ptp_canon_eos_get_viewfinder_image_handler (PTPParams* params, PTPDataHandler*handler)
> {
>         PTPContainer ptp;
> 
>         PTP_CNT_INIT(ptp, PTP_OC_CANON_EOS_GetViewFinderData, 0x00100000 /* from trace */);
>         return ptp_transaction_new(params, &ptp, PTP_DP_GETDATA, 0, handler);
> }
> 
> 
> Marcus, do you think it is worth it digging further into
> ptp_transaction_new()? Hm … seems like that's basically
> ptp_usb_getdata(). Anything to possibly optimize there? I added some
> more timings …
> 
> 
> lead-up ms 0 0 0 0 0 0 10
> usb_getdata ms 1 1 1 1 -1 -1 -1
> usb_getdata ms 14 14 14 14 14 35 -1
> event poll 4 87
> cap took 103 ms
> lead-up ms 0 0 0 0 0 0 9
> usb_getdata ms 1 1 1 1 -1 -1 -1
> usb_getdata ms 9 9 9 9 9 30 -1
> event poll 2 99
> cap took 115 ms
> lead-up ms 0 0 0 0 0 0 7
> usb_getdata ms 1 1 1 1 -1 -1 -1
> usb_getdata ms 5 5 5 5 5 23 -1
> event poll 3 33
> cap took 42 ms
> 
> 
> So, ptp_usb_getdata adds 5 to 14 ms right at the beginning (the first
> call to ptp_usb_getpacket()) and then adds more time to total of 23 to
> 35 ms. I see more extreme instances, though:
> 
> lead-up ms 0 0 0 0 0 0 93
> usb_getdata ms 1 1 1 1 -1 -1 -1
> usb_getdata ms 87 87 87 87 87 182 -1
> event poll 3 186
> cap took 285 ms
> 
> Here, the USB data extraction took 182 ms, while code around that added
> further 93 ms. There are cases where the preview extraction is
> indeed well below the 40 ms required for 25 fps, but the variance is huge.
> 
> Looking at this near-optimal instance:
> 
> lead-up ms 0 0 0 0 0 0 9
> usb_getdata ms 1 1 1 1 -1 -1 -1
> usb_getdata ms 9 9 9 9 9 30 -1
> event poll 2 99
> cap took 115 ms
> 
> It looks like gphoto2 should have been able to deliver this frame in
> just around 40 ms. But something after the getdata delayed things for
> further 67 ms. So that's the params->getresp_func() call, I presume.
> 
> ptp_transaction ms 5 14
> lead-up ms 0 0 0 0 0 0 14
> usb_getdata ms 1 1 1 1 -1 -1 -1
> ptp_transaction ms 1 2
> usb_getdata ms 10 10 10 10 10 31 -1
> ptp_transaction ms 34 94
> event poll 2 97
> cap took 112 ms
> 
> Here, it's rather clear: ptp_usb_getdata() needed 31 ms, while the loop over 
> 
> 	/* get response */
> 	ret = params->getresp_func(params, ptp);
> 
> adds annother 60 ms.
> 
> Maybe this one case could be fixed (perhaps by ignoring responses,
> even?). But the wide spread of response times from the camera leads me
> to conclude that you just cannot rely on timely responses from the 650D.
> 
> Incidentally, as I attempted to try the Canon EOS Webcam Utility on a
> Windows box, I noticed that — at least _now_, as I remember differently
> — there is a suspicious gap in the supported models. Older ones and
> newer ones are on the list, but not the 650D.
> 
> My conclusion is that this model is just not suited to extracting video
> this way, and Canon noticed that, too. I'm going to try an HDMI capture
> device. Thanks for the pointers on that … and maybe I can use gphoto in
> future for other fun like timelapse shots.

Wow, well researched :)

We still need to read responses at some point in time, so we cant just skip it.

(Adjustment to skip it and read with next data set might be workable, but also
the camera could block if we do not drain its bulk queue.)

Usually the whole ptp transaction phase is camera or hardware bound, there might
be optimization possible, but usually its okayish.

You probably removed hubs inbetween and plugged it directly into the machine?

Also, as mentioned earlier, the camera processor can be overloaded if we poll
too often... Are all those returning images or also returning the busy error codes? 

Ciao, Marcus


_______________________________________________
Gphoto-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/gphoto-user