MVCtoAVI 0.3.1 Frame Error - AVS Forum
Forum Jump: 
 
Thread Tools
post #1 of 2 Old 09-09-2011, 07:24 PM - Thread Starter
Member
 
JohnSchultz's Avatar
 
Join Date: Jun 2011
Location: Beverly Hills, CA
Posts: 169
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 10
I noticed strange 3D artifacts for moving objects and traced the problem to a 1 frame error between L & R video streams. A workaround is to set the Sync Frame to 1 for the left eye in FirstLight if using MVCtoAVI 0.3.1. Alternatively, roll back to MVCtoAVI 0.3.0 (does not have this issue). This was with TD10 source footage.

To see the issue in detail, carefully scrub frames where an object is moving but the camera is steady (on a tripod, etc.). The object should move the same way at the same time in both frames (ideally something moving vertically as the vertical position should be exactly the same).

This problem illustrates why it is important to make sure both cameras are exactly frame synced when shooting with dual cameras (I had seen this issue before when shooting with non-synced dual cameras).

When using the Cineform codec, both versions of MVCtoAVI put a green line on the bottom of the frame (per Cineform this is an MVCtoAVI issue). If Progressive is enabled, the problem goes away (I keep it interlaced for a higher quality progressive conversion in PPro).

[EDIT]Unfortunately, found another file which has a frame offset error in 0.3.0, this time requiring a correction in FirstLight of 1 for the right file Sync Frame. The solution is to examine each file in FirstLight and remux with the necessary sync frame if there is a problem. Fortunately, the September release of FirstLight should handle MVC directly and this shouldn't be an issue anymore. This level of effort is still worth it to be able to edit in real-time in PPro. Interesting timing as Vegas 11 gets GPU acceleration soon[/EDIT]
JohnSchultz is offline  
Sponsored Links
Advertisement
 
post #2 of 2 Old 09-16-2011, 10:01 PM
AVS Addicted Member
 
Joseph Clark's Avatar
 
Join Date: Mar 2002
Location: St. Louis, MO
Posts: 10,358
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 28 Post(s)
Liked: 99
Quote:
Originally Posted by JohnSchultz View Post

I noticed strange 3D artifacts for moving objects and traced the problem to a 1 frame error between L & R video streams. A workaround is to set the Sync Frame to 1 for the left eye in FirstLight if using MVCtoAVI 0.3.1. Alternatively, roll back to MVCtoAVI 0.3.0 (does not have this issue). This was with TD10 source footage.

To see the issue in detail, carefully scrub frames where an object is moving but the camera is steady (on a tripod, etc.). The object should move the same way at the same time in both frames (ideally something moving vertically as the vertical position should be exactly the same).

This problem illustrates why it is important to make sure both cameras are exactly frame synced when shooting with dual cameras (I had seen this issue before when shooting with non-synced dual cameras).

When using the Cineform codec, both versions of MVCtoAVI put a green line on the bottom of the frame (per Cineform this is an MVCtoAVI issue). If Progressive is enabled, the problem goes away (I keep it interlaced for a higher quality progressive conversion in PPro).

[EDIT]Unfortunately, found another file which has a frame offset error in 0.3.0, this time requiring a correction in FirstLight of 1 for the right file Sync Frame. The solution is to examine each file in FirstLight and remux with the necessary sync frame if there is a problem. Fortunately, the September release of FirstLight should handle MVC directly and this shouldn't be an issue anymore. This level of effort is still worth it to be able to edit in real-time in PPro. Interesting timing as Vegas 11 gets GPU acceleration soon[/EDIT]

Thanks for that info, John. I'll look forward to direct support of MVC in FirstLight. Any info on whether it might support more fully automated processing of the files, as it does files from the Panasonic pro 3D camera? It's tedious to pair the split files manually for muxing. Or maybe you already have a way around that?

Joe Clark

Joseph Clark is online now  
Reply 3D Source Components

User Tag List

Thread Tools
Show Printable Version Show Printable Version
Email this Page Email this Page


Forum Jump: 

Posting Rules  
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are Off
Pingbacks are Off
Refbacks are Off