Hi, > At one point in the scene there is rapid movement whereby something solid > moves approximately 20% of the frame width within one frame. Playing at > fullspeed on the DVD player, the edges look a little jumpy as the movement > occurs. Freezeframing at this point (the player does internal > deinterlacing) reveals blocky artifacts on either side of this solid object > which roughtly trace the shape of the object's location in the previous > frame. The artifacts are the same colour as the object but with much less > intensity. There doesn't appear to be much texture within each block.
20% of the frame will completely defeat the motion estimator. You'd need enormous search radii to find the matching blocks... The areas where the block was/moved too would consequently probably be intra-coded which really eats bits. The 'shadows' may simply be caused by the high quantisation this would occur. Can you email (or put someplace where I can download) a short snippet which shows the problem? It would be a really nice test-case to check some of the internal coding mode selection algorithms in mpeg2enc! > I don't believe this is an interlacing issue. One possibility is that you have some kind of motion compensating/motion adaptive deinterlacer in your player. This will also be struggling with such rapid motion change. Depending on the algorithm used blocky artefacts might also be produced. What do the individual fields look like if you preview on your PC? > As far as I can tell, mplayer doesn't show these artifacts; it looks like > another "hardware player" decoding issue which I happen to hit (like > DPME :( ). Aaaaah - almost certainly deinterlacer Artefacts then... > I have blocking in other places: if the scene is generally dark but with > some movement in places, the moving fetures tend to get blocky. I'm > wondering whether it's two issues - this I guess could be caused by the use > of -E. Another place I've seen it is if you have a scene which is faded > out over the course of 1-2 seconds. As it fades, blocky artifacts are > seen. Again, might this be due to -E? One big ommission in MPEG-2 is the lack of any kind of support for efficiently coding Fades. They encode really badly which provokes blocking unless you have a very high peak bitrate. The next release of mpeg2enc will have a feature to automatically smoothe an image (low-pass filter) it if visible blockiness would otherwise occur. The idea being a 'soft-focus' fade is a lot preferable to a blocky one! cheers, Andrew ------------------------------------------------------- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag-&-drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl _______________________________________________ Mjpeg-users mailing list Mjpeg-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mjpeg-users