get_movie_status - General Discussion and Assistance - CHDK Forum

get_movie_status

  • 5 Replies
  • 2837 Views
*

Offline kosy

  • *
  • 28
get_movie_status
« on: 23 / March / 2012, 03:16:34 »
Advertisements
I have a Canon A3300 FW Vers 100d and am trying to write a script that takes a round-robin series of videos. When the card fills up it deletes enough of the oldest videos to have room for the next one.

It mostly works but comes a cropper when I use a slower memory card or the card becomes fragmented. The issue is that using sleep is a bad idea because the timing of ending the movie is variable. I could use really long sleep delays, but then the gaps between movies is much longer than what I would like. So I want to wait the minimal amount of time, but long enough that I don't get errors.

Thus I tried using get_movie_status, because according to the documentation, it
"Returns status of movie recording.
can be used for stuff like checks instead of sleep commands. if get_movie_status is 0 or 1, movie recording is stopped or paused. if get_movie_status is 4, recording is in progress. if it is 5, recording is stopped but camera is still writing movie to sdcard."

Well, it doesn't quite work that way on my A3300 -- in the first place, on my camera the status result goes from 1 while it is writing to the card to 6 -- a value that is not mentioned in the documentation. And it stays at 6.

The second issue is that the camera is NOT done writing to the card when the status changes from 1 to 6 -- about another 0.3 seconds of sleep is required. I can see this clearly because I am showing the status on the OSD upon the change, and it pops up well BEFORE the "Busy" message goes away.

Oh yeah, if I don't add that 0.3 seconds of sleep the camera misses the following button-push. So it's important to wait until the Busy message is cleared.

Is there a method that will actually tell me when the Busy message is cleared?

Here is the segment of the script that's giving me grief:

function EndVideo()
   press("shoot_half")
   sleep(100)
   press("shoot_full")
   sleep(100)
   release("shoot_full")
   sleep(100)
        release "shoot_half"
   -- wait until finished writing to card
   O=get_movie_status()
   S=""
   while get_movie_status() == O do
       S=S..O
       sleep(100)
   end
   print("GMS1: ",S)
   sleep(300)   -- still need to wait for Busy to go away
   print("MS: ",get_movie_status())
end

BTW, I get between 10 and 12 passes through the while loop before the status changes.

Thank you for your help!

*

Offline reyalp

  • ******
  • 13443
Re: get_movie_status
« Reply #1 on: 23 / March / 2012, 16:04:18 »
get_movie_status returns the value of an internal variable form the Canon firmware. Like most things obtained this way, the exact behavior is poorly specified and subject to variation between models.

It's possible the address used on your port could be wrong, but it is "correct" according to the sig finder, so it's probably the same variable used on some other cameras.

I don't believe the thing that controls the "busy" indicator is know.
Don't forget what the H stands for.

*

Offline kosy

  • *
  • 28
Re: get_movie_status
« Reply #2 on: 23 / March / 2012, 23:56:32 »
Hi reyalp, thank you for the info.

It seems to me that it is safer to emulate button pushes than it is to invoke Canon's routines, many of which are imperfectly known. To do that well, however, requires some way of knowing when the button-push has been dealt with. I'm contemplating looking at the Motion Detection code, which looks at the LCD/TV buffer, and making a special version that instead of looking for motion looks instead for icons or messages. When the proper response is noted in the buffer, we know the camera is ready for the next button-push.

Does that seem like a reasonable approach?

I far prefer closed-loop systems where there is confirmation that the "message" -- in this case button-pushes -- has been received and the receiver is ready for the next message. I've noticed a large timing variation depending on the speed class of the SD card, fragmentation level of the directory, and other things which I have not identified. To make the open-loop system robust requires quite long wait states for each of the button-pushes, the result being inter-video gaps of nearly a quarter-minute. I would like to maintain robustness but cut the average inter-video gap to a few seconds.


Re: get_movie_status
« Reply #3 on: 24 / March / 2012, 00:08:00 »
Does that seem like a reasonable approach?
I think it can work well BUT will be very specific to each camera.
Ported :   A1200    SD940   G10    Powershot N    G16


*

Offline reyalp

  • ******
  • 13443
Re: get_movie_status
« Reply #4 on: 24 / March / 2012, 00:37:07 »
I'm contemplating looking at the Motion Detection code, which looks at the LCD/TV buffer, and making a special version that instead of looking for motion looks instead for icons or messages. When the proper response is noted in the buffer, we know the camera is ready for the next button-push.
The UI is displayed in what we call the "bitmap buffer". Motion detection works with what we call the "viewport buffer". You could certainly watch the bitmap buffer changes and respond to that, but as waterwingz says, it would likely be even less portable than get_movie_status.
Quote
Does that seem like a reasonable approach?
I would personally look for a variable that reflects the state you want. It must be tracked in the canon code somewhere.
Don't forget what the H stands for.

*

Offline kosy

  • *
  • 28
Re: get_movie_status
« Reply #5 on: 25 / March / 2012, 00:33:27 »
Thank you reyalp for the heads-up about the bitmap buffer -- otherwise I'd be looking in the wrong place.

Yes, looking for the icons and messages would be pretty camera-specific, but I feel it would make _my_ cameras operate more robustly.

And yes, it would be better to use Canon's own information, but that's not very well documented.

I have a lua script running now on the standard build for the A3300 that's finally running pretty well. It may be good enough after all, but I need to let it run for several days before gaining any real confidence in it. If it does work satisfactorily I will post it for everyone's benefit.

Waterwingz and reyalp, thanks again for your help.

 

Related Topics