Your video is tiny like a post stamp, meaning it's probably some mobile phone video that didn't look all that glorious to begin with since it was heavily compressed. Any additional processing will inevitably degrade it further, especially due to the fact that AE always decodes everything fully and hence any artifacts in the source file will come through as if they were intentionally part of the video. Your video will never look "sharp", least of all when again using a compressed format for output.
Thanks for the reply. I made my animation from scratch using graphics prepared in Photoshop. There is no video artefact in my source file, just PNG and JPG files, which leads me to believe that it must be an issue with those?
I attach another screenshot - of the 'output preview' in Media Encoder alongside the the actual file created with the settings from my first post.
Here's the problem as I see it. Your image does not precisely line up with the pixel grid, your type is very small and your lines are very thin. As Mylenium said the size of your video is very small. You also are trying to judge video output with Scale to Fit turned on. That's going to foul up the alignment of the pixels. We can't tell and neither can you if your video is loosing quality unless we see a screenshot of the original and the rendered output at 100%. You have also picked a non supported h.264 frame size. See This: H.264/MPEG-4 AVC - Wikipedia, the free encyclopedia. This almost guarantees something weird is going to happen to pixel interpretation.
What are you going to do with this video? I can't imagine a scenario where a compressed video of this size would be used. If you intend to nest this graphic inside another project then the video should be at least uncompressed and frame based. Single pixel wide lines cannot be smoothly animated because there's just not enough information to smoothly move across the screen unless you turn off anti aliasing or move the line an even number of pixels on each frame. For example, animate a single pixel wide horizontal green line moving up the screen at the rate of 1.5 pixels per frame would be green and one pixel thick on the first frame and two pixels wide and lighter and some other lighter green and two pixels wide on the second frame, then back to 1 pixel wide and green on the third. If the movement was different the change would be even harder to look at. Diagonal lines or rotating thin lines have even more problems when animated if they are very thin. That's just the nature of animation. This is why most animated instrument graphics that you see in movies have nice glows around them. If they are big enough to read on screen then they have lines that are 3 or 4 pixels wide.
If you absolutely must have a h.264 compressed movie that is small then use a legal frame size, carefully position each of your lines exactly on the pixel grid and be careful with any movement. If the lines must be one pixel wide then turn off antialiasing (set the layers to draft mode).
Thank you for replying. Unfortunately the video has to be in h.264 format and in this small size. The video will be displayed in a web browser with HTML 5.
The Media Encoder output preview options (Scale to fit, Scale to fill and Stretch to fill) all give the same crisp result.
My issue is not so much that the animation is not smooth, but rather that static objects have bad quality.
I've made a simplified animation with large and small text and a moving line. The animation has the same settings as seen in my first screenshot, but as you can see the quality has changed (more dramatically with the small text). Upping the bit rate does not improve things either.
MPEG compression (h.264 is MPEG) has a limited color space, compresses color, and has specific frame sizes that are required. Also, your media player has limitations and scaling problems. So do web pages. Nothing is perfect. The green text against the bluish background is going to look bad when you throw in compression artifacts from color and the fringes around the green text against the white background are also color compression artifacts. The solution is to first, modify the design to colors that work. You have to be sensitive to the color requirements of the space you are working in wither it is TV, WEB, Print or any other media. Most of these problems are color compression artifacts caused by the limited color space and limitations of MPEG compression.
The best hope for a design like this test to work is to first, make sure that your output is a legal h.264 size, second choose colors that will work against white backgrounds, third render a lossless master and finally, use that lossless master as the source for your MPEG compression in AME. You also make sure that your media player is not scaling the video.
If you absolutely have to have the video 392 X 640 then you are going to have resizing artifacts with H.264. You either have to accept that or change design of the web page and the HTML 5 code for the player. You also need to consider HR displays like the Retina displays on Macs or 4K displays on Windows machines or the displays on new mobile devices because they are going to want to see video and images that are 2X as big as a standard display. You'll also have to code for HR displays in your HTML. If this were my project I would make the master comp the nearest 2X the size needed for a standard web page that was a supported h.264 frame size, carefully choose my colors and design with known limitations in mind, render a lossless master in 10 bit or better 444 color, then send that to AME for compression. The web page would then be designed and the player coded with the video size taken into consideration.
Thank you very much for your in depth reply. I will take into consideration everything you advised! I hope I can sort this out!
I've tried re-making the comp x2 and then exporting it as the smaller size noted but it is the same 'soft' finish. I even tried a legal frame size with a preset of PAL D1/D2 Square Pixel (as I'm using square pixels for aspect ratio), but nothing good. The frame rate was upped to 25 and increasing bit rate doesn't affect it. Used different players and web browsers for playback - the quality is not high. Creating a lossless avi and then converting with Media Encoder doesn't work either.
What's interesting is making an even smaller framesize generates worse quality and colour changes, supporting the theory that a legal frame size is crucial. It's just very annoying that it's not possible to generate sharpness in smaller frame sizes.