[Denis Devlin]

I didn’t find anything in the Color form that seemed relevant.

The work around seems to be:

1) Render in Color with ” de-interlace ” unchecked.
2) Send back to FCP using the export codec (ProRez HQ) for the new sequence. (The imported sequence shows an orange bar – needs rendering for playback.)
3) Make a new sequence and drag in the render file that was created by Color (drag from the video from the imported sequence).
4) accept the “change sequence settings to match clip” dialog that is displayed when dragging in the asset.

This seems like not too obnoxious a work-around, even if I am mystified by why it is necessary.

The more important question though is why the work-around doesn’t help when the encoding in Color is set with the de-interlace option checked ON. Or perhaps more to the point:

what does Color actually do when configured to create a de-interlaced ProRez file from a progressive source?
and why is this different from Compressor creating a progressive ProRez file from the same progressive source file?

[Denis Devlin]

I suspect (hope !) that the footage will look ok on a tv, just like it looks ok using VLC. But, I am not convinced the issue has anything to do with interlacing and it still seems inexcusable that the Apple DVD player behaves so badly.

Here is some Apple documentation for Compressor:

*******
About Standard Definition MPEG-2
Standard MPEG-2 is full frame rate (23.98–29.97 fps) and full-screen resolution (720 x 480 for NTSC and 720 x 576 for PAL). MPEG-2 has the following characteristics.

Support for interlaced video: MPEG-2 can support either interlaced or progressive video.

HD to SD Downconversion
For those situations in which you are editing high definition (HD) sources in Final Cut Pro and want to create a standard definition (SD) DVD from them, Compressor provides high-quality downconversion. Compressor retains as much detail as possible during scaling and correctly preserves progressive or interlaced formats when encoding to MPEG-2 for DVD.
*************

I believe that DVD players that are rated to support “progressive scan” will properly interpret the “progressive format” which is output by Apple’s compressor. Presumably, Apple’s DVD player application also knows how to correctly interpret and play the progressive format mpeg. Perhaps in my example, something has gone wrong with the encoding so it is not correctly output as progressive – but then why does VLC not stumble in the same way?

[Denis Devlin]

The original footage is not interlaced – it comes from Sony Ex1, 720p60. Compressor is setup to produce a progressive mpeg encoding – not interlaced.

There are no relevant options that I can find in either the Apple DVD player or in VLC. Both are using defaults and there is nothing much that can be changed. The display size in both cases is “actual size” (I posted just a portion of the actual size screen image).

I suppose a DVD player is the best way to decode mpeg-2 content and then view it on a tv screen, but having seen the extreme difference in these images, do we also need to test on various DVD players to see which decodes well versus poorly? And in this day and age, many people do actually play dvds on their computer. Is the conclusion as simple as: “use VLC instead of the Apple player in order to avoid extreme artifacts in some cases” ?

Although this comparison of DVD player versus VLC is not directly relevant to FinalCut , it does seem valuable to point out that the final quality of a video image does seem to depend in some cases dramatically on the player used to view it. And perhaps there are specific encoding parameters that would avoid the problem illustrated by the frame grabs. That is my reason for posting here – maybe others have run into similar problems and figured out a work around. I am also interested to know if anyone has examples where the Apple player works well but VLC makes a mess out of the image.

[Denis Devlin]

I have experienced a more severe “glitch” as documented here:

https://forums.creativecow.net/thread/142/863389#863397

(follow the links if you want to see the footage – 11.5 Meg).

Its not clear to me if the problem is really similar or not – my example evidently involves several frames. Also, unlike the example above, my equipment was all new. I have not seen the problem occur again since getting a replacement memory card. But it was not a reproducible problem anyway, so its not at all clear that replacing the card is relevant one way or the other – and I am not running the camera for hundreds of hours so the evidence is hard to evaluate.

[Denis Devlin]

Check this thread:
https://forums.creativecow.net/thread/142/863310#863379
Your problem seems a bit different, but maybe related?

[Denis Devlin]

Craig Seeman,

Your “I can show you …” screen capture used to respond in this thread is quite effective – I like the zooming and attention highlights.

Which tool did you use to make it?

-Denis

PS: sorry for the off-topic response in this thread. Please advise if there is a better way to ask this kind of thing.

[Denis Devlin]

But if you are controlling the shutter speed manually (instead of turning off the shutter or letting the automatic exposure control it), then can’t you control the amount of smear or blur based on the shutter?

With shutter turned off, it seems that 60p capture is going to show ‘half’ the smear of 30p. But setting the shutter to 1/60 or faster for both 60p and 30p should smear about the same. Note: setting to 180 degrees would give 1/120 (for 60fps) versus 1/60 (for 30fps) – not the same as setting both to the same shutter speed.

And then with equal shutter speeds, we are back to the question of what happens when you down convert to 30fps mepeg-2. My test seems to say the doubled number of frames in 60p doesn’t give any benefit after down conversion.

[Denis Devlin]

Bob, thanks for the dialog.

Here is my test:

1) Use Quicktime Conversion to export a 15 second clip from the XDCAM 720x60p source. Save as uncompressed 59.94 fps (same frame rate as the source).

2) Use Quicktime Conversion to export this same clip uncompressed, but this time at half the frame rate, 29.97.

3) Bring these two exported clips back into FCP and insert both into an uncompressed 59.94 fps timeline.

As far as I can see, these steps yield the expected results:

1a) Comparing the exported 59,94fps clip to the original XDCAM source – I can’t see any difference.

2a) Comparing the clip exported at 29.97 to the original 59.94 source – I can’t see any difference when comparing the export to every other frame from the original (e.g. the export seems to have simply dropped every other frame as expected).

Note that the when both clips are brought into the 59.94 uncompressed timeline, the 29.94 clip needs rendering because every other frame is missing. After rendering, I was a little surprised to see that the missing frames were just filled in with a repeat of the previous frame – there was no interpolation.

Now the crucial test: use compressor to export my uncompressed timeline that is composed of exactly the same clip at the two different frame rates. Will the compressor make any use of the extra information in the 59.94 fps portion when it does the conversion to standard mpeg-2 NTSC video at 29.97fps? To my eyes, no!

The portion of the mpeg-2 movie that was compressed down from 59.94fps looks the same as the portion that was compressed down from 29.97. Some of the fast motion portions are blurred by the lower resolution of NTSC and by the mpeg-2 compression. It looks significantly worse than the 720p source but I can’t see any difference between the portions coming from the two frame rates.

My tentative conclusion: if the ultimate format is going to be 29.97 fps and there will be no slow-mo or effects that change speed then the extra “temporal resolution” of shooting at 720x60p is not used in the conversion to 29.97. So its better to allocate the 35Mbs data limit of HQ XDCAM for spatial resolution. That means either 1080x30p or 720x30p. And if there are going to be digital zooms, pans, centering, etc. in post then it seems like the 1080x30p would be the best starting point.

Are my conclusions wrong – I don’t have any real experience to back them up. Just a few experiments and trying to understand how all this stuff probably works. Note: my experimental clip is string players with bows whipping around in fast passages. Maybe a similar experiment using a clip where the camera is panning (so the motion is full frame instead of localized) would show very different results? Anyone done similar tests for panned footage?

[Denis Devlin]

Thanks for the response – and you probably won’t be surprised that I’m still confused.

Assuming that no slow motion effects will be applied, what is gained by shooting 60p instead of 30p?

As you point out, 60p gives a full frame available as source for each interlaced output frame (NTSC), but assuming that the desired output is going to be progressive anyway, these interlaced frames will be merged back together – so it seems like you would want to be pulling the interlaced half frames from the same source frame rather than adjacent source frames.

In other words – II don’t understand how the extra information available in a 60p source can give any significant benefit when it is transcoded to a 30p output. Or, relating my question back to Alan Roberts analysis for BBC: I don’t understand how the “jerky motion” that he sites as a characteristic of 1080/30p can be avoided by shooting at 720/60p when both will be transcoded to 30p for final viewing.

[Denis Devlin]

I too have lost confidence in the reliability of the Sony EX1 or the SxS recording medium.

In my case, the files transfered successfully using XDCAM Transfer but 18 consecutive frames were corrupt. Since the transfer program did not notify of any problems, its not until editing and looking at the individual frames that the problem becomes apparent. I posted the gory details a while back:

https://provideocoalition.com/index.php/forums/viewthread/31/

Since making that post, I have received a replacement memory card – but without any real reason to believe that the original memory card was or was not the cause of the problem. I’ll add a bit of additional information to my original post: the replaced memory card was a 16GB SxS card from Sandisk. Now that you have identified problems using Sony cards, it seems more appropriate to cast some suspicion on all cards and/or the camera to memory interface.

When dealing with tech support at Sandisk I was advised to try recording to the suspect memory card again to see if the problem recurred- It did not. But as I explained to tech support, this kind of testing could at best offer slight assurance against future problems and small comfort: I had already lost critical frames in a concert performance. There is no way to do it over.

I begged the Sandisk support people to give me a memory test tool. Surely there is such a tool available for quality control in the manufacturing process. But support was unaware of any such tool. When asked if I was able to reproduce the problem on the card, I answered “yes” even though in my several hour long tests filming blowing leaves on a tree I did not see a problem (but did I inspect at every frame? I am not sure.).

I am familiar with memory problems in the context of computer systems. Failure symptoms can be quite difficult to reproduce in daily use but catastrophic when they do occur. The only feasable way to track down and isolate the distinction between memory chip and memory controller, for example, is to run a diagnostic program that methodically writes various bit patterns to memory and then compares to a read.

It would seem in the best interest of everyone involved (Sony, Sandisk, and Ex1 users) that such a memory checking tool should be made publicly available before further confidence is eroded. I am still using the Ex1 as the single camera at classical music performances, but it is always with fear and trepidation that I take my first look at the footage after a concert.