The file systematically quits 20 seconds on any render in Compressor, suggesting some kind of container corruption.įurthermore, although the file did play in QuickTime Player X and QuickTime Player 7, scrubbing the playhead sometimes caused the application to crash! While ffmpeg successfully added timecode, the resulting file was a disaster for editing. Also, by default, ffmpeg only preserves 1 video and 1 audio track. Note: the timecode seems to be automatically calculated based on the framerate of the video track. Many programs like Handbrake are built on it, so I was excited to learn it can add timecode as well! To rewrap a container with timecode the syntax is like so:įfmpeg -i Day_1.mov -codec copy -timecode 04:25:50.00 Day_1.ffmpeg.mov ffmpeg Woesįfmpeg is the open source king for video compression. Repairing even small nicks from original footage, it serves a a trustworthy partner in the initial post-processing logging and transfer workflow. ConclusionĪt the end of the day, EditReady is the most reliable way of rewrapping and adding timecode to any footage. Thus, always rewrap footage first before beginning editing. While the cause is unknown (roundoff error maybe?), the implication of the change in number of frames is clear: rewrapping footage will make relinking offline media a nightmare! Attempting to relink the timecode version with the original brings this lovely dialog: Thinking this might have been the potential missing frame correction, I checked against another clip that rendered properly in Compressor, but the EditReady rewrap (without timecode) was again greater in frames: 174150 vs 174149. The rewrapped video however was larger in the number of frames: without timecode generation, it was 159165 frames instead of 159164 and with timecode it was 159166. Strangely enough, QuickTime Player 7 did crash a few times when scrubbing both. The size of the rewrapped, timecode footage is the same within a few bytes. However, clicking the + icon in the upper right allows one to add a timecode tag as well! (By default, if the field is blank, timecode will start at 00:00:00:00). By default, EditReady will preserve timecode if present, but not generate it if absent on the original. Rewrapping with EditReady makes Compressor super, super happy.ĮditReady’s rewrap affected the FCP X date at first, but turns out it was because there were conflicting dates inside the container’s metadata!ĮditReady’s Metadata window calls this to your attention and allows you to select and/or set which date you would like.Īs you can see the original file does not have any timecode. It could have been a bad SD card or something during the original shoot.ĮditReady’s algorithms can correct this, so it’s really the most versatile program out there. EditReady is a little better about moving past those segments. You hit one bad segment and it just gives up. When I had written regarding the ghost render, Colin at Divergent Media explained:Ĭompressor isn’t good at recovering from bad frames, so that’s the mostly likely problem. Divergent Media makes excellent products and their customer service is bar none. EditReady Lives up to Its NameĮditReady is a champion at rewrapping footage. The file was then transcoded with Compressor to check its integrity. They however, did not have timecode.Īfter timecode was added to the MOV container, the file was opened with QuickTime Player 7 and Compressor 4 to verify timecode. The following tests were performed using AVCHD files already in MOV format as imported on a MBP with Photos. Read on for the details and why others didn’t cut it (no pun intended). Short answer: EditReady is the most robust rewrapper out there, and can even be scripted from the command line. Unlike MP4, MOV supports timecode tracks full out, and rewrapping from MP4 to MOV can be done in a number of ways! But which are robust and which go bust? MOV containers are like the Swiss army knife of containers. Although Apple supports timecode in MP4 containers since 2013, other software may exhibit side-effects reading timecode-rich MP4s if they do not expect it. MP4 containers don’t traditionally support timecode which may help to explain why the recent trend in dropping timecode. Prosumer cameras really benefit from the compression because then 4 hrs of 4K can still fit on a 128 GB SD card. H.264 is a compressed video format originally intended for delivery, not editing, but its role has slowly evolved. Prosumer camera codecs like AVCHD and XAVC-S write H.264 video in MP4 containers. Timecode tracks can save mountains of time when editing multicamera shots, relinking media files, trimming clips precisely and so on-which, ostensibly, most home video footage won’t call upon. It’s one of the chief drawbacks that knocks the otherwise brilliant Sony AX100 from solid professional use. Newer, prosumer codecs these days like Sony XAVC-S don’t seem to record video with timecode.
0 Comments
Leave a Reply. |
Details
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |