Save to Movie duplicates or skips frames

Steps causing the bug to occur

  1. Create simple composition to read (Play Movie) a 100 frame video (Labeled frames 0 - 99), and save it using Save to Movie.
  2. As composition is running, creating its output file, watch it in a window linked to the play video output.
  3. The window will display the video frames properly, running from 0 to 99.
  4. Close the composition loader
  5. View the created movie. It will have the correct number of frames, but randomly the same frame will be duplicated once, and the frame that should follow is dropped. The phenomena does not seem to be related to anything I can find - playback speed or anything else.

Have you found a workaround?

No

Other notes

  • Vuo version: 1.2.3
  • macOS version: OS X 10.11
  • How severely does this bug affect you? It prevents me from completing a specific task with Vuo.

I have tried using the fire periodically node pausing and playing the playback node, and the same double frame skip the next occurs randomly.

I would be glad to share the 100 frame video test case I have been using if that would be helpful

I have added the file demonstrating the problem. Other test files with varying number of frames behave similarly.

I am attempting to write video special effects software, and the random duplicate frame/skip frame makes accurate special effects work impossible

After additional testing, the problem only happens with the H264 Codec. Neither the ProRes, nor JPEG codecs show the problem. This largely eliminates my problem, as I will want to write to editing codecs rather than delivery. This reduces the bug severity for me to minor.

It may be a problem for others.

A thought - if your H264 implementation involves other than I frames it may be some time stamp interaction between the frame time and the way the intermediate frame is being created.

While trying to reproduce your problem, we noticed that stepping with the arrow keys in QuickTime Player X sometimes shows the same frame twice, whereas QuickTime Player 7 shows the frames correctly.

If you haven’t already, @David, could you try viewing the output movie in QuickTime Player 7 and/or Vuo’s “Skim Movie” example composition (Vuo 1.2.3)?

Both QT7, QT10, and Final Cut Pro X show the skip/double frame phenomena in the vide3o encoded with the H264 CODEC. All played the ProRes CODEC without problems. All tests were done by incrementing/decrementing 1 frame at a time

Ok, I did a test. I can confirm that QuicktimeX skips frames, but the frames are there on Quicktime7. However, more interesting to me is that the output video frame rate is not 24, and I am guessing this is why QuicktimeX is skipping frames. The original video is 24 frames, and the output video is 24.14 FPS. I don’t think 24.14 is a ‘standard’ frame rate. Is there a way that Play Movie or Save to Movie can honour the framerate of the original file? Maybe Save to Movie could have a framerate input?

@David, can you confirm what framerate your saved video from Vuo is? If you dropped the video into a timeline in FCPX that was already 24p that would explain why you are getting dropped frames in FCPX as well. I don’t think FCPX allows non-standard frame rates. (and I don’t think that 24.14 is a standard anywhere).

Media-Info Analysis:

PS: I used the supplied video file from @David. Also disregard the duration, I just let it play a bit too long in Vuo. I also tested this with export movie, (so Vuo in image generator mode) no issues with that, 24FPS export is fine. Plays back fine in QTX. So looks like QTX doesn’t like non-standard frame rates- and QT7 does.  

Confirmed — with H.264 output, Save to Movie sometimes generates movies with faulty frames.

We were able to reproduce the problem consistently by inserting a computation-heavy node (Frost Image with Iterations turned up) between Play Movie and Save to Movie. This caused some frames to have incorrect timestamps in the output movie. When playing back the output movie, frames would be skipped or even appear out of order.

@David, just to make sure that we’re seeing the same problem you are, would you mind attaching one of your output movies that skips/duplicates frames?

By the way, another reason that Save to Movie might skip frames is if the Play Movie node’s Decoded Video trigger port is dropping events. You can avoid that either by changing the trigger port to enqueue events (at the expense of the composition possibly lagging behind and using more memory) or by restructuring the composition to fit the Image Generator protocol and using File > Export > Movie.

@alexmitchellmus, movies output by Save to Movie actually have a variable framerate. The timestamps are based on when Save to Movie receives the event. The rate varies slightly from one event to the next.

We’re planning to modify the Save to Movie node to accept a timestamp together with the image (just as Play Movie fires a timestamp along with the image). This would allow for exact framerates.

(You can also get exact framerates with File > Export > Movie.)

This bug is not completely reproducible. This time when I duplicated it, QT7 plays it fine, as does ProPlayer and FCPX. QT10 jumps around. I am supplying the test composition, the input file, and the H264 output file. Note that there are no issues at all with SavetoMovie set to encode in Prores

Simple Video Test.vuo (2.58 KB)

I had discovered that the framerate varied. This is a potential problem for executing special effects video, as I am doing. I append an image at a time, and the fps vary based on my speed of adding the frames. I have been fixing that problem, by recompressing these variable frame rate files in Apple’s compressor, exporting to another ProRes video.

What would be ideal, is to allow appending frames to an existing movie at any rate, and have the resulting video framerate be specified independently, as a property of SavetoMovie. Animation is typically done a frame at a time, with various times required to manipulate the frame. Each frame is recorded when it is completed. The resulting recorded string of still frames is designed for a given specified frame rate (24 or 30 in US). For me, the workaround has been saving a folder full of sequential frames, and using QT7 to import them as a movie, allowing the constant FPS to be set during import.

@David, thanks for the output video. Yep, it does look just fine in QuickTime Player 7, and the FFmpeg utility ffprobe says that 100 frames are present. On my computer, it also looks fine in QuickTime Player 10, maybe because I’m on Mac OS 10.8. So yeah, as @alexmitchellmus was looking into, maybe later versions of QuickTime have a problem with variable framerate movies.

If it’s not too much trouble, could you post an output video that exhibits duplicate/skipped frames in QuickTime Player 7? Again, just trying to make sure that we’re looking at the same problem.

To specify a fixed framerate, have you tried File > Movie > Export? I’ve attached the equivalent of your Simple Video Test.vuo as an image generator suitable for movie export. This might simplify your workflow.

MovieExport.vuo (1.09 KB)

I cannot reproduce the error with QT7. I probably made some mistake. Withdraw that portion of the “bug”.

As a side note, all of Apple’s professional SW occasionally shows odd behavior when using variable framerate material. The workaround that seems to work is to reencode the video with compressor to the desired frame rate. This gives you a video with constant frame rate, and works fine.

Several other applications using H264 and AVC wrappers produce files

@David — OK, thanks for checking.

Good to know about the Apple software flakiness with variable framerates. All the more reason for us to add support for exact framerates in Save to Movie.

Vuo now supports exact framerates in Save to Movie, as of Vuo 1.2.4.

We haven’t yet been able to fix the bug with frames being duplicated or skipped, but we have found a workaround: change the Play Movie node’s Optimization port to Random. (Play Movie chooses between two video libraries, AVFoundation and FFmpeg, depending on the movie file format and the Optimization port value. The bug involves one of them, AVFoundation. Setting Optimization to Random forces the node to use the other library.)

Fixed in Vuo 2.0 beta.