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
