For all of you who are having Motion Menu render problems - try this

Question

Just humour me for a minute.
I have another Sonic application, and a known bug in the Motion Menu rendering applies to 29.97DF projects only.
IE, NTSC.
Often the video in a motion menu will fail to mux.
There are workarounds though.
1 - Make sure your GOP structure is 15 at most
2 - Make certain the frame length of your video file is divisible by the GOP structure. IE, it must be a multiple of 15 frames.
3 - if these both fail, reduce the bitrate of the video 500kbps at a time until it muxes. Most will work at 7,000, some need to be 6,000 and there are even times when you need to go as low as 4000.
Try it - Encore uses a Sonic Authorcore, so it's worth a look.

Answer 1

>Are you saying that NTSC 29.97 divided by 15 is okay?
Not really.
What I am saying is that your movie frame length should be divisible by the GOP structure with a GOP of 15.
With NTSC video, you can have GOP lengths
i up to
18, but it is not mandatory to go to 18 - 15 is a perfectly acceptable figure. You could use a GOP of 12 if you really wanted to. What this means is typically the number of frames between I-Frames.
MPEG-2 encoding (AKA "Moving Pictures by Educated Guesswork") P & B frames work something like this:
i P-frames provide more compression than I-frames because they take advantage of the data in the previous I-frame or P-frame. I-frames and P-frames are called reference frames. To generate a P-frame, the previous reference frame is reconstructed, just as it would be in a TV receiver or DVD player. The frame being compressed is divided into 16 pixel by 16 pixel macroblocks. Then, for each of those macroblocks, the reconstructed reference frame is searched to find that 16 by 16 macroblock that best matches the macroblock being compressed. The offset is encoded as a "motion vector." Frequently, the offset is zero. But, if something in the picture is moving, the offset might be something like 23 pixels to the right and 4 pixels up. The match between the two macroblocks will often not be perfect. To correct for this, the encoder computes the strings of coefficient values as described above for both macroblocks and, then, subtracts one from the other. This "residual" is appended to the motion vector and the result sent to the receiver or stored on the DVD for each macroblock being compressed. Sometimes no suitable match is found. Then, the macroblock is treated like an I-frame macroblock. The processing of B-frames is similar to that of P-frames except that B-frames use the picture in the following reference frame as well as the picture in the preceding reference frame. As a result, B-frames usually provide more compression than P-frames. B-frames are never reference frames.
In short, the I-Frame is the full description reference frame. A P frame is also a reference frame but describes the difference between the last I-Frame & itself. A good analogy is when you are on the telephone & describing what you see to a friend. The initial background description (The street, the sky, what you can see etc) would be an I-Frame. Then you describe a person walking down the street - that would be your P-Frames, as you are only describing the i changes
in the scene.
The bitrate can also affect things - I mentioned this too, and if a motion menu will not mux, first make sure that the film length is divisible by the GOP, and that the GOP is 15.
If it
i still
won't mux, drop the bitrate by factors of 500 until it will.