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

On Sat, Dec 26, 2020 at 01:47:05PM +0100, Marcus Meissner wrote:
> 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? 

one more thing ... is EOS webcam on windows handling it better?

Ciao, Marcus


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