Frozen frames with 600D/T3i: Canon, ML or SDHC to blame ?

[1%]

Look at your files with bit rate viewer in frame mode. See if there are drop outs in the frozen spots.

[benoitvm]

Look at your files with bit rate viewer in frame mode. See if there are drop outs in the frozen spots.

Is that really relevant ? The problem is the same during standby...

[g3gg0]

Following my email, the regional Canon support center (France for my country) has called me to explain that what I am seeing "is normal because of the H.264 compression technique used, which uses keyframes when the picture changes significantly and hence a few identical frames are following the keyframe, etc..." (or something very similar)

i just DLed your video and had a closer look at it.

cannot confirm this. that freeze not starting from an I-frame.

last "good frame" is no 178, this is a P-frame. the next frame 179 is also a P-frame is "stuck" and has the same content as 178.
no 180 is an I-frame and 181, 182 and 183 a re P-frames again.

so we have 5 stuck frames based on P178:

P179 I180 P181 P182 P183

good P-frames have here about 90k memory usage, the "stuck" P-frames have about 7-11k and show a lot zero coefficients.
the next good frame (P184) contains mainly "intra" macroblocks (80%) that basically contains image contents.
this means, it is nearly an I-frame (but not tagged so).
the stuck frames starting from 296 are twice as large, but rest is the same.

conclusion:
so it seems, the MPEG encoder itselfs does everything right in terms of encoding. I-frames every 12 frames, P-frames are encoded correctly.
they seem to forget to update the MPEG source data? as they use 3 buffers AFAIR, a simple firmware bug that forgets to update one buffer might *not* be the reason.
maybe thats really in MPEG unit - do they have a 6-frame buffer for motion detection?

[benoitvm]

considering the results of your investigations, and the fact that the problem occurs ALSO when the unit is not recording (standby), I guess it has noting to do with encoding, but rather somewhere else in the handling of the camera controls by the CPU. Something like a synchronous call to a routine that handles iris operation, suspending all other processing until the iris has successfully changed value (in my observations, the symptom described is synchronous with iris opening changes in auto exposure mode).
I escalated to Canon tech support here in Belgium, but I had no answer so far.
Will post any useful answer I get from them.

[1%]

Here is my example of it freezing when I took the raw:

http://www.sendspace.com/file/ovomq5


The image that came out is the same as the first frozen frame. I've never seen this problem in LV, thankfully.