TMPGEnc's MUX is BAAAD!

[JQ]

There is definitely something wrong with TMPGEnc's (version 2.59) multiplex and demultiplex routines. I have a VCD format and XSVCD format video that play perfectly when burned straight to VCDEasy and played on an appropriate stand-alone DVD player. However, when you multiplex them in TMPEnc, the audio and video go out of sync. This is the case with both MPEG-1 and MPEG-2. In addition, when you de-mux the videos, the video stream does not play properly at all. In fact, I used VideoLAN and PowerDVD to play the XSVCD and they played perfectly from the captures. (And burned correctly and played perfectly on the stand-alone DVD player as well). But after the MUX in TMPGEnc, both of these could not be played correctly by either player and the DVD player did not play them as they were supposed to be played. The audio was way out of sync with the video. I originally was MUXing because I wanted the XSVCD to play on a VCD only player. It worked except for the out of whack audio-video sync. What in the world is going on?!! Does anybody else know what other program does the "Header Trick" with MPEG-2 files except TMPGEnc?? (And PLEEEEASE don't say bbMPEG because my capture board (an ATI Rage Fury Pro) will only capture in AVI and MPEG2 and the AVI sucks because (I believe) my hard drive is too slow (and too small) to capture well. I tried Huffy format AVI and MJPEG as well. Bad results IMO with MJPEG and Huffy wasn't recognized by bbMPEG. MPEG-2 is also not recognized properly by bbMPEG even though it says it should. And yes, I have the MPEG-2 plug-in. I'm referring to the fact that when you bring an MPEG-2 file up, it will only see the video, not the audio stream for conversions. What's up with that? In fact, when you burn it, ignoring the lack of audio source, there will be no sound or in some cases, sound that wavers in pitch and cuts off eventually. AND, if you force it to use the same MPEG-2 file as a sound source as well, it won't recognize it. That's even with the system-video+sound option on. HMMMMPHHH!)

[vitualis]

How did you multiplex them? What setting?

Regards.

[JQ]

I used both multiplex and simple multiplex and just browsed for the mpeg-2 file that I captured. I then set it to VCD standard so that the header would be changed to play in a DVD player that can only play VCD's. Just like the manual. I also experimented like I said above with multiplexing files that I knew would work in a DVD player as is (burning with VCDEasy) and found that those files were also out of sync after the MUX.

[vitualis]

Don't use "MPEG-1 Video-CD" setting for anything other than VCD spec MPEG-1 files.

Try "MPEG-1 Video-CD (non-standard)".

Regards.

[BJ_M]

i dont know much at all about that capture card -- but working backwards here , lets see :

you 'browsed' for your mpeg2 file you cap'd .... doesnt the capture card cap a program stream mpeg ? or is it elementary streams with a seperate audio and video stream (if so they should be cap'd on different drives).. (audio from sound card) . (i said i dont know these cards)

assuming it IS a program stream .. did you de-mux the files first ?
not knowing ati real well but well enough to know they are the king of non standard -- i would de-mux the mpeg cap'd no mater what it was .. plus re-mux it with the audio IN THE CORRECT format in which the file is FIRST ... check that file and see if it plays ok ..
Then demux that file and re-mux with vcd header ....

tmpgenc 2.59 has no problems with its mux or unmux ..
and bbmpeg is very good also ...

VCD and SVCD use 2324 bytes Pack size , DVD uses 2048 . The muxed bitstream is broken up into these 'packs' with a pack header starting each one and they contain 1 or more PES (Program Elementary Stream) packets (chunks of the video or audio stream). The Packets/Pack setting specifies the number of PES packets that are placed in each pack. VCD, SVCD and DVD always want 1 PES packet per pack.

The Pack value specifies the starting timecode of the muxed stream (this can be different than the starting timecode of the video stream). It is arbitrary as well. The Video, Audio1 and Audio2 delays actually specify the starting time of the respective stream (relative to the pack delay). If these settings do not match the streams will start at different times. Normally they are the same, but say you had a video stream and an audio
stream where you know the audio actually starts 500ms after the video, you would set the video delay to some value and set the Audio1 delay to video delay + 500, this would then synchronize the two streams when muxed.
in your case i should think the values would be the same - unless the ati and sound card have a lot of latency .

some other problems with muxing -
time stamps - timestamps are needed for synchronization of video and audio. In general, it is enough to set this option to I-Frame. Pad VCD Audio: Some VCD burning programs require this flag to be set and some do not. VCD video packs are 2324 bytes long, but the audio packs are only 2304 bytes long. When the data is written to a VCD disk, the audio packs are put in normal 2324 byte sectors. Some VCD burning programs deal with the extra 20 bytes themselves, while others require the extra 20 bytes to be present. When this setting is enabled, the audio packs are added with 20 zero bytes so they are 2324 bytes long, if not enabled the audio packs are only 2304 bytes long. This setting is only meaningful VCD.
SVCD defines some navigation information that is put into the video stream to help players jump back and forth or skip ahead easily. The info is called scan offsets, this option is normally required for SVCD. This option will be ignored if the user mux rate is set higher than allowed for SVCD. and if you re-mux to vcd it is stripped off.

a big mistake is the buffer - VBV , both in the muxer and in encoding and they are not the same buffer (nether buffer accually exists but is a hypothetical decoder with a buffer whose size is specified by the Video Buffer Size. Encoded pictures from the MPEG stream are placed into the buffer (hypothetically) and removed from the buffer at regular intervals. The MPEG video stream is supposed to be constructed by varying the size of the encoded frames such that the buffer does not underflow (i.e. becomes empty where there are no frames in the buffer when it is time to decode one) or overflow (i.e. becomes full where no space is available for more encoded pictures).
VBV is the abbreviation of Video Buffering Verifier.
These settings (VBV buffer size in the muxer and in the encoder) specify the size of the buffers needed to decode the video and audio. If it is too low, you will get buffer overflows, which could show up as stuttering video and/or audio. Usually it is set to the same size as the video VBV buffer although the VBV units are half these units say dvd is 232VBV , mux video buffer then be typically 224 - 232 ).
when you do the vcd header trick - you are changing one of these values to a lower number -- which in software decoders (on a pc -- they really dont care at all (rememeber its a fake buffer anyway) , but in hardware the VBV value and multiplex buffer are very important .. I dont know what TMPGenc does in terms of these values when do theheader trick -- but of course it seems to work for a large group of people ..

A Lot of people post here asking abbout problems with stuttering video and many times the relationship between the VBV and the video buffer in the multiplexer is a main area to investigate ... as you get into higher bit rates - it becomes more importaint (and one of the reasons why the best multiplexors cost 2000 - 4000$ just for the multiplexor - yes we own some of these.
It is NOT the only reason though it can happen .....

anyway, i wandered off the topic ..