Field Order/Dominance question

Question

I've been noticing that spots I've produced that air on my local cable network appear to be having problems with jerky movement of elements created in Motion. I thought that maybe the field order was set wrong on my Motion projects. (I should add that I'm doing "the big no-no" by only monitoring these on my computer and not on a TV monitor. I know, I'll have to remedy that someday.) Anyway, I'm using the "NTSC Broadcast SD" preset and that means field order is lower/even. I'm definitely rendering these out with field rendering on (Apple ProRes, btw) as I can see the interlace combing when viewing the output file.
I thought I'd try an experiment by creating a Motion project that would expose interlacing problems in the worst way and then render it out of Motion three ways: lower, upper and none. I then encoded these to mpeg-2 using Squeeze and burned them to a DVD (in DVDSP) to view on my consumer DVD player and SD television. (Remember, that's the only way I can view them played back interlaced...) To my surprise both the upper and lower movies looked terrible and the one rendered with no field dominance looked the best.
What gives? Any ideas? Does this seem right?
Thanks!
--Kurt Cowling

Answer 1

Wow Iain, you know waaaay more about this than I do. In fact, I asked a question in the iDVD area of this board many moons ago regarding whether or not there was some sort of metadata or tag that let iDVD know if the incoming file was interlaced or progressive and the response was basically "I don't know for sure, but I don't think so".
Anyway, I can confirm what you say regarding the output of ProRes files. The content is interlaced, but when clicking the deinterlace button in the advanced area of QuickTime player nothing happens.
I tried as you suggested and opened the "Advanced..." area of the output settings in Motion and found that interlace was indeed not checked in the ProRes settings. When I output a file after checking that box I can also confirm that the deinterlace button in QT player did actually deinterlace the display of the file.
I normally output my Motion projects in several layers and bring them back into FCP (as rendered video, not Motion files) to composite them with the underlying camera footage. (Makes later changes and updates easier to deal with for my workflow.) I then export the composite out of FCP as uncompressed SD and then proceed to encode for FTP delivery from there (usually H.264). I opened a recent uncompressed file that was output from FCP and found that it suffered from the same problem, namely that the file was not tagged as interlaced, even though the content was interlaced.
I then opened one of the H.264 files that was encoded from the uncompressed master. Same issue again.
The one thing I haven't tried (yet) is outputting my test project from Motion as described in my first post (but with the files tagged correctly this time!) and see if the DVD that gets burned plays correctly. I will try this in the next day or two.
I don't know what happens to my files after I FTP them to the cable provider, but I assume they must transcode them from H.264 into their system. If the files aren't tagged as interlaced then their system is probably treating them incorrectly, as well.
This brings me to the final question(s) that may solve all of this for me:
Is there a way to change just the metadata/tag in an existing QuickTime file (so that it is tagged correctly as interlaced) without having to re-render from the beginning? Also, It appears that FCP may suffer from the same issue since it obviously uses QT to export, just like Motion. If I correctly tag a file rendered from Motion and then import it into FCP and FCP doesn't then pass the correct tag on output to uncompressed I still have the same problem. Or, if FCP tags the uncompressed file correctly, but QT doesn't pass this along to the H.264, I'm still screwed. Hence, my question at the top of this paragraph! I think I really only need the last file I handle before FTPing to have the correct tag, since the content has been fine all along.
Thanks so much Iain for looking into this! I would never have found this on my own. I'm not exactly sure if this is a bug or just a bad implementation, but this seems like a bad oversight for sure and not something that could be figured out from reading the manual.
--Kurt
p.s. I will try some more experimenting with this and hopefully can come back and marked this thread as "question answered" since a workaround seems doable. Iain, would you be willing to submit this to Apple as a bug report? You seem to have a much better handle on this than I do.