David's picture

Status: 

Vuo version: 

OS version: 

  • Mac OS 10.11

How severely does this bug affect you?: 

●●●○ — It prevents me from completing a specific task with Vuo.

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: 

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

Comments

I have added the file

David's picture
Submitted by

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

David's picture
Submitted by

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

jstrecker's picture
Submitted by

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

David's picture
Submitted by

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

alexmitchellmus's picture
Submitted by

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

jstrecker's picture
Submitted by
Status:
Waiting for review by Vuo Support Team
»
Scheduled for work

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

jstrecker's picture
Submitted by

@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.)

I had discovered that the

David's picture
Submitted by

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

jstrecker's picture
Submitted by

@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.

I cannot reproduce the error

David's picture
Submitted by

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

Vuo now supports exact

jstrecker's picture
Submitted by

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.)