This content has been marked as final. Show 7 replies
I can't see the problem you mention. Perhaps you are seeing the mismatch between your computer display's frame rate and the movie's frame rate? One way around that is to add motion blur.
However, if you render with fields, every other horizontal line will be offset and horizontally moving things will be "jagged." How will you display the video? Interlacing/fields should only be used for video that will be displayed on a TV. Always use "progressive" for display on computers.
i http://livedocs.adobe.com/en_US/AfterEffects/8.0/WSbaf9cd7d26a2eabf53ab041041081290f-7fc9 .html
- Jonas Hummelstrand
Thanks for the suggestions. This video will be played on either a computer screen or through a video projector system, so I tried "no fields" first, then the other options. I see the same effect regardless of the field order (or lack thereof).
Are you saying you do NOT see a flickering or strobing type effect about half way up the sides of the moving box? Like sections of the vertical gray line go black for a brief time?
I see it on all three computers here. All my monitors are set at 60 Hz, and that should be more than adequate for a 30 fps video, no?
I will try the motion blur and post the results to this thread.
Never got around to trying motion blur. Solved the problem another way. When I paused WMP at just the right time, I was able to freeze that defect I was talking about and see it there in the still image. That told me it wasn't a monitor or display issue, but something real in the video itself.
It wasn't there in AEP, where the video was created. It wasn't there in the monitor window of Premiere. But it was in the exported file.
So I changed to the tried and true Cinepac codec, and though the file is 10x larger, the defect is gone. It was an artifact of the orginal codec (MS MPEG-4 Video Codec V1 and V2). The Indeo codec works well too, producing a file 3x larger.
Lesson learned. The most efficient codec is not always the best, depending on source content. Probably old news to you experts.
Thanks again for the reply.
>Lesson learned. The most efficient codec is not always the best,
>depending on source content. Probably old news to you experts.
Not necessarily. The problem probably could also be solved by changing some encoding settings. Because MPEG uses moving blocks to create the illusion of motion, it's possible that some of them may end up at the wrong position at a given frame which would create such artifacts. Enforcing different block sizes or changing their distribution could potentially resolve such issues. I also wouldn't rule out performance issues. MPEG-4 is very hungry and may not play perfectly on powerful computers...
What you say about MPEG-4 being "power hungry" confuses me. From what I read, it is often used for streaming content on websites. That would seem to say that it's a lower bandwidth format, and should "play nicely" with most machines.
If what you meant was that it requires more power for encoding (in a reasonable time), that would make sense. Do I understand? Or am I still confused.
Also, I know what you mean about the encoding settings. There aren't many choices when one uses Cinepac or Indeo 5. But with the MPEG-4 encoders (I tried Xvid and MS V1 and V2) there's a plethora of settings, but little in the way of explanation. It may have been possible to get that MPEG-4 encoder to work without producing the artifacts I was getting, but I'd have been guessing at which settings to tweak ... largely a trial and error process.
If you know of a good online source that explains all these MPEG-4 settings, I'd appreciate a pointer in that direction. I'd love to get those file sizes down a bit. Thanks.
>If what you meant was that it requires more power for encoding (in a
>reasonable time), that would make sense. Do I understand? Or am I still
Yes, it uses a lot of resources for encoding, but also upon playback. The point here is that while it has low data rates, MPEG 4 uses a bunch of computationally intensive tricks. This can be any combination of variable GOP lengths to non-square, adaptive block sizes. If you will, because the files contain very little "real" pixel information, a lot of CPU (or graphics card) power is spent on reconstructing from the compressed info. You will not see this that much at low resolutions, but if you ever downloaded e.g. one of the HD-res QT clips from Apple, you could see a lot of processor activity while playing them. You can find some good info on MPEG encoding on forums like Doom9. There is also some tech blurb explaining the principles and differences between various implementations on the developer sites for TMPEG, XviD and SUPER©. Beyond that you can of course always check the official docs from the MPEG licensing group or organisations such as ITU, but that may go way beyond what you are trying to understand. In relation to the Adobe Media Encoder, the decisive factor is the GOP length. You may wish to shorten it from the default 15frames to something like 7. Be aware, though, that this will unavoidably increase average data rates, regardless how you set them. Also use VBR encoding, if you can and have the extra time. if you can#t get decent results from within AE, simply export uncompressed and use one of the tools I was mentioning.
Many thanks for the lucid explanation! I now have a much better appreciation of the limitations and advantages of MPEG-4. Issue closed.