[Marc Brown]

> can you verify the term RAW

My bad. “Raw” is my shorthand for “uncompressed.”

> Did you rebuild an AE project based on an mpeg video as your reference? Or did you convert the mpeg video itself from 29.97 to 23.976?

Within AE, I imported the original 29.97fps mpeg2 video, did my edits (this involved performing reverse pulldown on different segments of the video, as the phase kept changing from scene to scene), and allowed AE to output the result as an uncompressed video some 130GB in size. 8 bpc, I do believe.

> What resolutions are your AE comps, clips and ppro sequences?

AE comp is 704×480 NTSC non-widescreen 23.976fps, as is its raw output which I use in PPro. The other source – an mpeg2 video – is 720×480 NTSC widescreen 23.976fps. The PPro sequence is its preset for DV NTSC widescreen 24fps.

In spite of the variability between the two source videos (widescreen vs. not, and differing resolutions), I again stress that no degradation of either video is apparent in PPro’s video preview prior to the uncompressed render, yet BOTH sources get degraded in the same manner upon rendering.

[Marc Brown]

Thanks for the information. In this case, the considerations you point out were not completely misunderstood by me.

I point out that the degradation I am seeing is happening here:

Input: raw video (exported from AE as raw)
Output: raw video (exported from Premiere Pro through Media Encoder as raw)

No compression is inherent in the raw source. Hypothetically, no compression should be taking place in the raw export. The degradation I am seeing is NOT visible on the input file (raw from AE, remember) prior to export. Also I need to be specific in saying that the input file is not an AE project file but an actual raw render.

[Marc Brown]

Thanks for replying.

No deinterlacing per se. There are two source materials in the same timeline and the degradation affects both:

1: A mpeg2 video (from DVD) at 23.976 progressive fps.
2: A raw 23.976 progressive fps render from AE which was itself originally a 29.97fps mpeg2 video from DVD which I painstakingly reconstructed in AE with reverse pulldown.

To compare footage (before and after Premiere Pro sends it through Media Encoder, whether for “raw” or mpeg2 encoding), I consult Premiere Pro’s preview window, zoomed in to 400% so I can discern finer detail. The kind of degradation which occurs certainly doesn’t require close inspection to be recognized.

I had considered for a moment that perhaps what I was seeing was a loss of chroma resolution, due, at least in the case of mpeg2, to the nature of the video format. But this wouldn’t make sense, because all of the source video WAS originally mpeg2, so any loss of chroma resolution would already have been inherent. And besides, that would do nothing to explain why the supposedly raw renders undergo the same degradation.

[Marc Brown]

No argument. If I had a raw 1080p file in front of me, I’d be rather happier. Unfortunately, what I do have is a DVD encode of a VHS tape.

Anyway, it looks a lot better now that I’ve gone through the considerable hassle of rendering off a 130GB raw file. I again question the wisdom of tucking pulldown removal away as a file interpretation rather than a temporal effect (or, ideally, both, so long as the need for raw renders is minimized).

[Marc Brown]

Blah. Debugmode Frameserver has a version which is supposed to work with CS4. I tried it. Once it hits Media Encoder, it crashes. And this is apparently common. And this is CS4 we’re talking about – hardly brand new. I have no hope for CS5.

What a stumbling block. The worst part is I can’t seem to find a raw video setting that doesn’t result in some sort of quality loss (generally in the form of ugly posterization that certainly wasn’t there before), so even that is out.

[Marc Brown]

Nah, what I meant was, say, XviD or Divx compression on progressive video which happens to consist of interlaced frames – both fields already interwoven. The reason this gives a poor (and more importantly, less than ideal) result, as well as the fact that such a result is intuitable, is similar to the reason why noise reduction in my case is also less than ideal if done in the wrong order.

In my frank opinion, the “remove pulldown” feature in After Effects should have been something one could put on an adjustment layer, not a one-shot process that has to be done at a specific point in one’s workflow. In terms of its ultimate purpose, it differs little from similar effects like Timewarp. The fact that I’m having to resort to the good ol’ raw video to get my job done attests to the validity of this opinion.

[Marc Brown]

Pretty simple, actually. The noise in question is largely of the mpeg2 mosquito and megapixel variety. These artifacts are of a consistent nature on their individual frames – ie the two fields of an interlaced frame, which are stored as two half-frames in one image.

Any kind of interlace-related modification to these frames (pulldown removal, for example) will chop these megapixels into an interlaced weave of artifacts. If a noise reduction effect is designed to work on whole frames (meaning both fields in a frame), it should be obvious why allowing such interlace manipulation prior to the noise reduction would complicate matters. Instead of working its magic on predictable noise, it has to deal with noise that has been woven together at the finest vertical level.

Perhaps this might help: Have you ever seen a video that was encoded while still being interlaced? It just doesn’t work out too well. There are reasons.

[Marc Brown]

Okay. Actually, my old AE CS4 handles the mpeg2 footage quite well.

But if you’re saying that the reason I can’t interpret my 29.97fps comp as 23.976 with pulldown removal (the option is grayed out) is specifically because it contains interframe video, well, I suppose that’s that.

Seems a bit odd, though. As I said, I do not experience any anomalies which would suggest AE is freaking out over the footage. I have even loaded the AE comp up into PPro, and even that kind of boat rocking hasn’t generated problems.

[Marc Brown]

> Yes, you did preface it that way. And then in the remainder of your post made it quite clear editorially that you considered these Encore issues.

A preface is like turning on italics at the start of a paragraph. It’s a good method of subsequently making points without having to repeatedly stress a certain fact. Editorial legitimacy is a topic perhaps better suited for movie review talkbacks.

> […]never had a problem[…]It’s transcoded.[…]Buttons on menus do not get lost.[…]

You and I were using different versions of Encore CS4. Should I have made videos of these phenomena? Possibly so.

> Invisible buttons when not selected might be one method of authoring a menu (it’s one that I would never use – how does the user know what to do if there’s not a clear indication of where the buttons are?)

The button graphics are part of the motion menu, of course. Adobe’s own info page on this topic has this to say:

For example, you can create a video in After Effects in which the button images fly in from different points and settle into position after 15 seconds. In this case, the background video, not the menu, includes the button images.

Clearly, the concept of preexisting button graphics is not something I more or less uniquely invented. In fact, every DVD I’ve ever authored has utilized this kind of idea.

[Marc Brown]

Thanks. Indeed, as long as somebody knows what they’re searching for – the same kinds of information I was seeking at the time – my post ought to save a lot of time.

The disappointing truth is that it boils down to issues of stability and capability. Crashes have to be actively circumvented. Much minutiae has to be absorbed through the process of trial and error, because the intuitive assumption is frequently the wrong one (which I again contrast with my experiences with other Adobe products). Certain capabilities one might justifiably take for granted are inexplicably beyond Encore’s scope, even after a full year since Blu-ray implementation with CS3. On it goes.

As for the recommendation about memorizing Encore’s mechanisms in detail in order to circumvent headaches, the only specific case in which that suggestion is applicable is that of menu transcoding, in whose case I am to accept that foreknowledge is chiefly a defense against the combination of Encore’s inability to transcode in anything better than MPEG2, and its failure to notify the user of the potential transgression of intent while giving the user a choice of codec for menu-designated video.