Avidemux does use libavcodec to do any encoding (not sure if static, however), but that still leaves two different scenarios:
1) The blocking is due to not cutting on I frame or GOP boundaries. In this case, the 'blocking' would probably look more like smearing, since it doesn't have all the data. To remedy this, programs might use a smart encoding process that will decode only those portions affected by a bad merge so that all the data is retained, and then re-encode that portion so that all there aren't any adverse artifacts.
2) You're encountering a case of libavcodec's bad rate control, especially in the event of joins that incur a smart encoding method (again, I don't know if Avidemux does smart encoding). My tests of libavcodec as an MPEG-2 encoder a few years ago showed that it had pretty bad RC that was most obvious at the very beginning of a stream and then lessened as encoding progressed. I've not done tests with a current version to know whether this has been improved - FFmpeg's git log does show that there have been fairly recent commits that affected the MPEG-2 encoder, so it's possible that it has. That's no guarantee that Avidemux is using that updated code, though (especially in the case of Avidemux under Natty; the more recent MPEG-2 commits were from September).
Bookmarks