I use ffdshow (if that's not selected it defaults back to DivX 5.2 and XviD 1.1.3), and I certainly don't see a sync problem even when 2 are selected, regardless of which one is doing the decoding or whether Packed Bitstream is selected also or not. As this was the source of the problem then a sure-fire way to bypass the issue, as I'd suggested testing earlier, is using MP4 or MKV and allowing the video stream to be Native MPEG-4 rather than specially hacked to fit inside of AVI. The problems experienced here deal explicitly with the issue of AVI not supporting B-frames and thus to have them, they need to be hacked in.Scintilla wrote:I would say yes, reduce it to 1, but be aware that this will hurt your compressibility somewhat.Kero777 wrote:Should I now reduce the "Max consecutive BVOP's" to 1? I did my tests with 2 and it was fine, but if I don't reduce it to 1, what will happen exactly? Compatibility/sync issues for people who don't have XviD?
However, that page is a few years old by now, and the newer versions of the DivX decoder may not have this problem anymore. I would suggest installing a copy of the DivX codec (version 5 or later), encoding the video with FourCC DX50 (DivX should then be the first choice to decode this instead of XviD, assuming you don't have ffdshow or have its DX50 support disabled), and playing it back to see if there are any problems.
The hacks simply come with a price (that is, potential audio desync), but because of how ingrained DivX/XviD-encoded AVIs are, putting them into a container that properly supports the B-frames, even if it is the one defined in the MPEG-4 standard, will make for people complaining at you because they can't play it back or have something against other containers (probably based on bad experiences or a preconceived notion that MP4 or MKV equals H.264 rather than MPEG-4 Visual - DivX or XviD - and therefore processor choke because on average, H.264 requires more powerful hardware).