Historically, VideoReader had only one property for asking about the number of frames. The original property operated by reading every frame of the video and counting them, and that was automatically done when VideoReader was invoked. But that was slow and often not necessary.
Mathworks then added a second frame count property that is initialized to an estimate of the number of frames, based on the time recorded and the nominal number of frames per second in the header. If some operation is done that reads through all of the frames then the property is updated to the actual number.
The estimated number of frames is not accurate for variable frame-rate videos. But it can also be off for NTSC frame rates because software is often sloppy about writing in 30 frames per second in the header, or at best recording 29.98 frames per second in the header, which is closer but still not exact.
Against all of this, it turns out that Microsoft's asf video format does not have the needed header information to estimate the frame count, so the frame count ends up being reported as 0... at least until some operation reads all of the frames sequentially.
Aashita showed how to read all of the frames and count them. Another way that in theory should work is to use readFrame to read all of the frames and throw away the results, after which the property should be correct. If reading all of the frames could overfill memory then you could loop readFrame a group of frames at the time, which should be more efficient than reading them one by one.
