1

Recording Keynote, slides with photos are choppy

• 2017 iMac — Retina 5K — 3.5 GHz i5 — 8GB Ram — Radeon Pro 575 4 GB
• OS 10.14.4
• ScreenFlow 8.2.3 — guessing not the Mac App store version, since when going to the App store it gives me the option to buy (my wife bought it, so not sure where bought)
• None: external devices recording from and how are they connected to computer 
• Recording to internal HD:   Scratch disk location in preferences if it's hard drive record or playback issue 
• 2.74 TB of 3 TB:  Free hard drive space 
• Using only iMac's 5k monitor
• Doesn't seem to be the issue: Complete Export settings if it's an export or encoded file playback issue 
• Various: Sequence running time 
• No Error messages

...................................................................................................

Recording Keynote presentation at 60p. Presentation plays in full screen while recording.

***Entire presentation looks smooth while it plays and while it is being recorded with SF8.

After ending the recording, some slides have smooth animation, some are choppy.

Choppiness of these select slides occurs inside screenflow, and also after exporting from screenflow.

The choppy slides contain photos, jpg's. Choppiness occurs on every slide with jpg's.

The choppiness is during transition between slides, as the jpg's slide into view.

I do have one slide—in the same presentation—with three png images, and their animation records smoothly. Choppiness occurs on the jpg slides only. These three png images are about 4 MB, approximately 2400x2400, then resized smaller within Keynote—Again, these png images animate smoothly in the recording, it is the jpg photos that do not. The jpegs are almost all smaller than the png's, most less than 1MB, most less than 2400px in any dimension.

...................................................................................................

Attempted to fix by the following, with no success:

– Converting jpgs to png. 

– Shrinking the jpg dimensions down to as low as I could before looking pixelated.      . . . . . .  Jpg file sizes: 543 KB, 104 KB, 187 KB

 

There are other slides in this presentation containing jpegs, they all look choppy in the SF8 recording. The above attempted fixes was attempted on just one of those slides.

9replies Oldest first
  • Oldest first
  • Newest first
  • Active threads
  • Popular
  • ... Keynote 9.0.1

    Like
    • CraigSModerator
    • Telestream Desktop Forum Moderator
    • CraigS
    • 3 yrs ago
    • Reported - view
    Daniel Heywood said:
    Recording Keynote presentation at 60p.

    Please clarify. Recording in ScreenFlow doesn't have 60fps, only Highest followed by 30fps. Timeline can be 60 fps but that might not be the best framerate option.

       

    Like
    • CraigSModerator
    • Telestream Desktop Forum Moderator
    • CraigS
    • 3 yrs ago
    • Reported - view
    Daniel Heywood said:
    Choppiness occurs on the jpg slides only. These three png images are about 4 MB, approximately 2400x2400

     They may be too large to decode properly. Smaller (file size) could be worse because it means more heavily compressed and, therefore, more resources needed to decompress. Consider that large ProRes files are much easier to play than smaller  H.265 files.

    Like
  • Thank you.

    I had "Record Desktop Framerate: Highest." Timeline is 60p.

    Results are buttery smooth on the slides not containing jpgs.

    You say this may not be the best framerate option. Why so?

     

    Just tested "Record Desktop Framerate: 30 fps", and it is less juttery on the jpg slides,  but still juttery, but then the rest of the slideshow loses its buttery smooth animations—guessing it to be just normal 30 fps jutteriness (and not an error like I am experiencing at 60 fps). I switched the timeline to 30 fps for this test.

     

    I am not sure about your meaning of:

    "Smaller (file size) could be worse because it means more heavily compressed"

    ... I do get that ProRes can play easier than H.265. So I suppose you are saying png compression is less a burden to decode than jpg compression. Which leads me to guess that screenflow does not "take a moving picture" of what is happening on screen, but is instead doing some decoding work and turning that decoded data into a video recording. Whatever is happening "behind the scenes", where I don't get your meaning about decoding is, I converted the jpg images on one slide to png, and the choppiness was still present on the recording of that slide. Also, my test of shrinking the jpegs down was to smaller dimensions (at highest quality), so they were smaller, not due to being more heavily compressed at the same dimension, but due to being shrunk down in dimension. These jpgs at smaller dimensions were still choppy when recorded. Not an argument against what you suggest, just a statement of what I did, and stating I do not have an understanding of how it fits in line with your statement.

     

    Is this an issue no one else has experienced?

    Like
    • CraigSModerator
    • Telestream Desktop Forum Moderator
    • CraigS
    • 3 yrs ago
    • Reported - view
    Daniel Heywood said:
    So I suppose you are saying png compression is less a burden to decode than jpg compression

     That may be possible depending on the file. File pixel dimension is an issue because that may demand real-time scaling. Files should be at your target frame size (1920x1080 for example). Also, files designed for print may be 300 dpi for example and video doesn't need more than the equivalent of 72 dpi (there's no actually dpi in video of course). High dpi files tend to be larger than necessary for video and that can also involve real-time resources.

    Please make sure files are at the targeted frame size. Please make sure they aren't designed for print (high dpi). 

    Keep in mind playback is impacted by a number of things. A recent quad or octo core i7 or i9 is going to handle playback a bit better than a dual i5 a few years old so issues like this may be system specific.

    Set recording to Highest and use the appropriate frame rate for the timeline. For Keynote it probably wouldn't need to be more than 30fps. 

    Using 60fps is also going to demand more resources and that's really designed for gaming or fast sports use.

    Like
  • CraigS said:
    dual i5 a few years old

    Nah, my iMac is quad core. It also has a Radeon Pro 575 4 GB, if that matters. Settings allow the graphics card when exporting, but maybe it is not used while recording? Also, my iMac is less than two years old (release date, or less than one year old in real life use).

    ... with this info, maybe your answer would be the same—"this may be system specific"— but it handles other intensive video work well, so I expect SF8 should be able to do right by the recording, but maybe not.

    ...............................................................

    With your suggestions, I could not get SF8 to record as smoothly as Keynote plays it.

    ...............................................................

    I did find a workaround that for this project, will suffice. Not ideal to add the extra step (it could be forgotten, requiring re-recording), but unless I can find another screen recorder that works as I'd hope, this will have to do.

    Workaround:

    I changed my screen setting to: System Preferences> Displays> Display> Resolution Scaled: Larger Text.

    When recorded, this creates a dimension of 3198x1800—less than the 3840x2160 I'm after, but it is a small enough difference that for my current project, when scaled up, it looks okay.

    With this screen setting—plus with Keynote's "Apply Motion Blur to Animations" turned on—SF8 is properly recording the smooth animation that Keynote is playing, for all of my slides. SF8 is set to "Highest" Desktop fps for recording, and exported at 60fps.

    ... But turning off Keynote's Motion Blur still records with some juttery motion on some of the animations—and with Motion Blur on at higher screen resolutions SF8 does not record smoothly.

    ...............................................................

    CraigS said:
    Using 60fps is also going to demand more resources and that's really designed for gaming or fast sports use.

    30fps is extremely juttery when exported by SF8, even if I use Keynote's Motion Blur. But 60 fps is creamy smooth.

    Like
    • CraigSModerator
    • Telestream Desktop Forum Moderator
    • CraigS
    • 3 yrs ago
    • Reported - view

    Daniel Heywood 30fps should be fine so there does seem to be an underlying issue. Keep in mind that recording Keynote is a common use of ScreenFlow and we're not seeing other reports like this.

    I can't comment on your setting without verification.
    That means setting recording in ScreenFlow to Highest and setting the timeline to 30fps. If you can provide screenshots of that, the frame size of your document (as shown be the Canvas Resize tool on the left side above the timeline) and a screen capture of the Keynote playing in the timeline, I can analyze further).

    You're clearly having an issue but many other users are recording Keynote in ScreenFlow and we're not hearing such reports. 

    Like
  • Try TIFFS instead of JPEGS. See the drama I had discussed in: 

    Short story.

    I discovered I was using a callout action (move, scale on an A0 print size) JPEG file, 7MB. A low res JPEG and even the A0 converted to TIFF (500 MB) worked fine! The latter somewhat over the top. There is probably a 'right size' TIFF or JPEG you can select that is suitable for a moving, scale up of a JPEG or TIFF. Perhps 2 or 4 x the target output dimensions? I guess....

     

    Mellalieu, P. J. (2021, October 13). How do I SIMPLY use Stock Media without getting choppy playback? Telestream Community Forum. https://telestreamforum.forumbee.com/t/60hg89z/how-do-i-simply-use-stock-media-without-getting-choppy-playback

    Like
    • CraigSModerator
    • Telestream Desktop Forum Moderator
    • CraigS
    • 1 yr ago
    • Reported - view
    Peter Mellalieu said:
    Try TIFFS instead of JPEGS.

     Certainly a suggestion worth trying.

    Peter Mellalieu said:
    Perhps 2 or 4 x the target output dimensions?

    Larger output dimensions due use more system resources for realtime scaling on playback but would be good on export though. Larger output dimensions are useful if you're going to animate the graphic through an Action (scale and/or reposition over time for example).

    Like
Like1 Follow
  • 1 Likes
  • 1 yr agoLast active
  • 9Replies
  • 93Views
  • 3 Following