Frame diminesions do not match in R2016a using getFrame function but same code executed in R2015b produces frames that have matching dimensions

53 views (last 30 days)
In R2015b I get:
Warning: The video's width and height has been padded to be a multiple of two as required by the H.264 codec.
In R2016a I get: ERROR: Error using VideoWriter/writeVideo (line 374) All 'cdata' fields in FRAMES must be the same size. Error in makeVideo (line 12) writeVideo(v,fr);
R2015b produces a video and R2016a does not.
The code used to generate the video data uses the "getFrame" function which produces frame data with matching cdata fields when executed in R2015b. However when executed in R2016a the frames do not have matching cdata fields.
I have discovered both R2016a and R2015b are able to create the video if the data is generated in R2015b. However neither R2016a or R2015b are able to create the video if the data is generated in R2016a. The code used in both versions is the same.
I think this points the "getFrame" function as the cause of the issue. What can I do to fix this error I receive in R2016a? 

Accepted Answer

MathWorks Support Team
MathWorks Support Team on 23 Mar 2016
The issue has to do with doing getframe on the axes, and the part of the axes being grabbed is off the screen. This causes the frame dimension mismatch seen in the cdata fields.
To resolve this, change:
data = getFrame;
to
data = getFrame(gcf);
to grab the figure instead of the axis.

More Answers (1)

Walter Roberson
Walter Roberson on 6 Apr 2023
When you have an axes, the drawable width of the frame can vary a few pixels smaller or larger, depending on the current axis tick labels. If you set the axes tick labels and limits manually, only changing the inside of the axes, then the axes should always end up the same size (as far as I recall.)
But if you have something like a scrolling plot where the tick labels are being updated dynamically according to the data, then the exact positioning of the tick labels involves some rounding that can result in small differences in the axes width.
The work-around is to imresize() the getframe() results to a fixed size. That will not affect any frame that happens to be exactly the same size, and should make only minor changes to frames that are close in size. You might potentially get a little blurring on the text.

Products


Release

R2015b

Community Treasure Hunt

Find the treasures in MATLAB Central and discover how the community can help you!

Start Hunting!