Simon Arnold
Forum Replies Created
-
I Know, why it can do this is shocking. You never want your original source messed around with but it does and I have tried it on all our systems and it does it on our clients systems as well. We have found however that it does seem to be files made from quicktime library or quicktime itself that cause the issue in FCP compressor is fine and conformed files from CT are fine. Just did another test. Had a clip that missed off the frame, we recreated it and then conformed in CT. All was fine in FCP with it. We then decided to rexport this file again from QT and low and behold it makes the problem reoccur.
Its a shame we cannot use compressor but it really is not up to the load we will put through it and it will not report back to our other systems like our current system does. Also they did try it before and vowed never to use it again in our general pipeline.
-
Because of the sheer number of shots and people we have rendering we it has to be an automated system. We have multiple versions for internal use, client sends etc. FCP is only used for managing and updating cuts and this is where we are noticing the discrepancies. Besides its not the audio that is causing the issue as it happens with or without it also the problem is only noticed and made worse when the files go in to FCP so that would never work. It seems to be the different way in which applications write the timebase in quicktime. FCP seems to be finicky in reading this data and rounds down were ever possible loosing the last frame, were as quicktime itself seems to leave it all alone.
-
Yes it does it on all codecs. It is to do with the framerate integers. If its a rounded frame rate of 24, 30, 25 all is ok but it seems to be an issue with 23.976 only on any codec.
-
No we are just making 48k 16 bit. We are getting somewhere. We have changed the workflow now so we use our in house tool to stitch an uncompressd 23.98 video stream created from shake with the correct audio for the shot. We then use quicktime then to re-export as 23.976 Pro Res LT. These still have the same issue although you can now conform them in CT. Having compared a conformed clip next to the file created from quicktime we have found the problem to lie with how quicktime makes the files and writes the duration in the file header. CT uses a higher integer counter so it gets more accuarate reading of the duration. FCP must use this frame counter, were quickitme itself gets the duration from the video stream length. Why FCP physically alters the original file is still an unknown factor.
-
Hi Jeremy,
you cannot choose 23.976 only 23.98 in shake. As for Cinema tools the conform button is greyed out so we cannot change the framerate to 23.976 which is what we normally do to fix the framerate and get back the frame we are missing. We have just tested a new workflow not using ffmpeg and using quicktime as the last stage an we still get a problem with FCP giving a performance error and altering the file so it drops the last frame. We did test making an uncompressed 8 bit file instead and all was ok so it seems to be an issue with the LT codec, which is odd.
-
Shake can only render at 23.98 and not 23.976, this can make FCP miss out the last frame but never actually alters the original file as you can always view the missing frame in QT. However in this instance it actually alters the file. I think it is actually down to how we are making the quicktimes as normally you can use Cinema tools to conform pro res but it is greyed out with our files.
I have spoken to our dev team and it might be down to the fact we are using ffmpeg after shake to add audio to the output as Shake can only do it manually and we need it fully automated.