I know Main Concept's h.264 encoder includes functionality like this so probably their MPEG-2 encoder does to.

But using either one of these will involve a re-encode.  Decode the current stream, then re-encode using your specified parameters.  If either or both of the bit rates are low you may see additional artifacts from this process.

I just have a utility that looks at the rate by computing it from the first PCR and then looking at subsequent ones until it appears to have converged, meaning the rate from the first to the Nth PCR isn't changing anymore.  That rate typically converges within the first MByte if the PCR accuracy is any good at all.

Assuming that you create CBR transport streams as output (it sure looks like it), the accuracy of your PCR calculations leaves something to be desired.  On one sample I ran the rate computed from PCR to PCR varies from

Min Delta Rate:        16847720 (-29984)
Max Delta Rate:        16907891 (+30187)

The rate determined by subtracting the last PCR from the first is 16,877,704 while the bit rate I compute after looking at the first MB is 16,877,805.  These differ by 101bps, which seems excessive (its outside MPEG-2 spec tolerance anyway).

You should fix this.

I would normally expect a transport stream to be an integer multiple of the 188-byte packet size in length, but that doesn't seem to be the case for TS's created by XMuxer Pro.  Not a giant problem, but you should fix it.

I was suprised by the lack of an options dialog in the multiplexer.  I need to create transport streams, but was expecting options for...

CBR or VBR (at least leave out the NULL packets) -- I need CBR right now
Bit rate -- should default of course, but user specified values should be allowed.  Just complain and fail if you can't fit.
PIDs -- it would be nice if you could control them, though I can live without this
I would have expected you to follow the T-STD buffer model automatically.  Not sure if you do this or not, but I would have expected a knob to set the buffer size.  For my applications 224K is typical (cable).
Synchronization -- often you may need to delay the audio relative to the start of the video or vice-versa to get lip synch.

Stuff like that.  Lots of other options occur to me too, but I don't know that I really need them.

I have at least one MPEG-2 transport stream sample that will hang the player, requiring a windows reboot.  I'm not sure why.  Other samples play fine.  The sample is a simple CBR MPEG-2 transport stream, 720x480 video.  It does have an AC-3 audio, but so would any cable sample.  I can supply a portion of this sample if needed to some ftp site.