Avidemux

Standalone MPEG-4 players

This article tries to help you make your videos play on standalone MPEG-4 DVD players,
whether they are DivX Certified [http://www.divx.com/en/partner/certified-programs] or not.

The packed VOP hack

B-frames are nice but they induce a one frame delay shift because a B-frame needs both its
previous and next I/P frames to be decoded.

That does not cope very well with VFW (Video for Windows) limitation that more or less
assumes one frame in/one frame out.

To workaround this, DivX, Inc. [http://www.divx.com/en/company] introduced PB frames in AVI. To

explain it, see the B-frames article. Basically they add a non coded image (N-VOP) after a frame
containing both a P and a B frame. Some (most?) players choke or stutter on that as it
artificially creates an additional frame. To detect that, they also put a specific marker in the
user data section of the MPEG-4 stream. Some players use that information to switch to packed
VOP mode, but it is not 100% reliable. Plus the stream is not 100% ISO compliant.

Rule #1: Don't use packed frames. With Avidemux you can't but with some other software
you can.
Rule #2: If you have some, depack them.

In order to do so, when prompted if Avidemux should depack such frame, say yes. Avidemux
will take each frame and scan for more than one VOP inside it. If it finds several, it re-creates
separate frames and destroys the corresponding N-VOP frames.

That will take care of the packed VOP, but the marker in user data will remain. To also remove
it, use “AVI, unp. VOP” as the output format instead of the usual AVI format and save the video.

That will scan and fix on the fly the marker so that the stream is detected as non packed stream.

That should solve all DivX encoded packed files, but may not work for some Xvid encoded files.

Warning: If the file has VBR audio, don't forget to do Audio→Build VBR Time Map after loading
it.

If you have a huge amount of such files to convert you can use a script like:

#!/bin/bash
export SRC=/tmp/fma2
export TGT=/tmp/fma3
perl foreach.pl $SRC/*.avi "avidemux2 \
--force-unpack --load $SRC/%f \
--audio-map --save-unpacked-vop \
$TGT/fixed_%f --quit"
GMC and Qpel
Xvid and libavcodec MPEG-4 can use more complete GMC
[http://en.wikipedia.org/wiki/Global_motion_compensation] (Global Motion Compensation) and Qpel
[http://en.wikipedia.org/wiki/Qpel] (Quarter pixel) models than the DivX codec.

With those, you are screwed and need to re-encode the video. That means dual-pass encoding
to keep the same size.

There is a way to get almost the same result using only one pass. Assuming your video is
correctly done, the previous encoding already distributed quantizers and bitrate to get a good
quality for a given size. Why not reuse that information?

To do so, set Xvid (or libavcodec(nbsp)MPEG-4) to use “Same Qz as input” mode. In that mode,
they will encode each frame with the quantizer used previously to encode it. The result will
have about the same size/quality compared to the original but using only one pass.

That can also be done using command line mode to process plenty of files in a row:

#!/bin/bash
export SRC=/tmp/fma2
export TGT=/tmp/fma3
perl foreach.pl $SRC/*.avi "avidemux2 \
--force-unpack --load $SRC/%f \
--audio-map --video-process --video-codec xvid4 \
--video-conf follow=1000 --save $ TGT/fixed_%f \
--quit"

Muxing
I have found that some software (like some version of nandub) does not mux the file properly.
That makes standalone stutter and freeze. The fix is simple: just load and save the file in
Avidemux.

tutorial/standalone_mpeg-4_players.txt · Last modified: 2012/11/11 08:51 (external edit)