I had it set to "By Ratio" and it wasn't displaying correctly.  I set it to "Custom" and 4:3 and it did correct the display.  

That does work, thanks.

However, I still think you have a bug to fix.  The sample I'm using is clearly labelled as a 4:3 sample.  It has the optional VUI header with the aspect_ratio_idc set to 1, which according to my reading of the h.264 standard suggests a 640x480 4:3 frame without overscan...

It's pretty common in cable anyway to use frame sizes that aren't 4:3 even though the sample is to be rendered on a 4:3 TV set.  So you might have a 4:3 sample that has a resolution of 640 x 480 (correct) but you would in fact more often see 544 x 480 or 352 x 480.  Anyway, these all play just fine if you send them to any cable STB I'm aware of (MOTs, SAs, Pioneer, Pace, Amino...).

However, when I play a 352 x 480 baseline AVC sample on Elecard's current player (4.0.4) with the current AVC plugin, I see a video that is squished (too narrow) vertically.  The player should really be expanding this up to the right aspect ratio before displaying it.

The sample AVC file I'm using DOES have the optional VUI parameters present and specifies the aspect ratio correctly.

I think I saw this with a progressive stream.  Please check.

Okay I just downloaded the new version and installed it (both Xmuxer Pro and the AVC plugin).  I uninstalled the old version first.

The program doesn't hang muxing these streams anymore, but the MPEG-2 stream it produces isn't quite right.  When I watch it on an AmiNet 124 set top box, I can see regular "pauses" where I assume the frame rate isn't being maintained.  Looking at the stream myself I can see a few places where the PTS's aren't being incremented properly.  For example, the first I-frame in the second GOP has a PTS +6006 larger than the PTS on the last P-frame in the first GOP (neither of these has any B-frames or reordering).  Not sure why, but this will result in the last P-frame of the first GOP staying on screen for two frame times, which is the kind of thing I'm seeing when I watch it.

It appears that most of the PTS increments are correct, even with reordering (later GOPs do have B's), but obviously some of them aren't correct.

In fact, looking at packet 8283 of the output, I see a PTS that PRECEDS the PCR time at that moment--the last PCR before this is at packet 8248 which has a PCR value of 167426784.  Since this is a CBR stream at 2Mbps, the PCR at 8283 would be +710640 from that or 168137424.  Converting this to 90kHz for the PTS comparison, we get 560458.  But the PTS on this frame is 559709, which means this frame CANNOT be displayed.

You've got some problems in your PTS/DTS computation logic.

None of these problems are in the original stream, before running it through the demux/remux process.  I'm using the same progressive Ateme sample as before, and checking "Use padding" and setting the desired bit rate to 2000000.

When demuxing an MPEG-2 transport stream containing AVC and MPEG-1 audio, the progress bar goes solid blue almost immediately and then the disk chugs away for some minutes longer.  Obviously it would be better if the bar indicated the status of the demux.

Note: this could be related to the other bug I posted about the preview slider.  In this case though, its relatively simple--just use the % bytes thru the file statistic.

The sample I gave you is a transport stream.  Transport streams have PCRs.   If the sample is CBR, then the PCRs will quickly converge on a rate if you just calculate bytes between PCRs / time between PCRs.  If it is a CBR stream, then you can just look at how long it is in bytes and convert that to time.  Easy.  Of course this is transport time rather than play time, but these will generally not differ by much and should be sufficient for the slider.

If the sample isn't CBR, then you could use the PCR delta to figure out the length in most cases, though some samples might have PCR discontinuities in them.  Here you could simply look at the first PCR in the sample, and the last PCR in the sample.  The delta will be some number of 90kHz ticks.  Since PCRs are 33 bits they will only roll over after 26 hours or so, so a simple delta should work fine.  Again, this should work most of the time.

If however the sample is not CBR and has some PCR discontinuities, then...

Works fine with the updated code.  Thanks very much.

Using the Mux panel with an AVC elementary stream and an MPEG-1 audio stream to produce an MPEG-2 SPTS, if I look at the resulting transport stream I see:

A PAT at packet 0.

A PMT at packet 1.

A PES header at packet 2 with PTS 22172, and DTS 19169
followed by a SEQ, VUI, PIC, SEI, and finally an IDR-SLICE for an I-frame.
(p.s. packet 2 should really have a discontinuity flag set to force the PCR to be loaded)

A PES header at packet 27 followed by a P slice.  Problem is the PTS on this frame is also  22172.  In theory only one of these frames should display as a result of this collision.

The next frame (a P) follows at packet 28 with a PTS of 25175, which is fine, but a DTS of 22172, which since it conflicts with the DTS of the previous frame, means this frame might not get decoded.  Which would be bad.

This appears to just be a startup problem, since things work fine after that.

I'm running updated sent by Vladimir on 6-22.  It now correctly handles h.264 progressive video streams from Ateme's h.264 encoder.

However, if I feed it an interlaced sample, it doesn't work properly.  The PTS's on the fields increment by 3003 (its NTSC) even though they should be incrementing by only half-that since they are just fields, not frames.

The resulting stream plays fine on your MPEG Player, but I suspect it won't on a real h.264 set top box (for cable or telcom), since these have to respect the time stamps.

There are other problems that probably result from this--some of the DTS's and PTS's are before the current PCR time, meaning they likely will be discarded rather than displayed.

In Muxer panel.  Open h.264 ES.  Open MPEG-1 audio.  Copy all (>>).  On right hand pane I see:

- Transport stream
  - Program #1 (ID 16)
    - Audio(PID 224 ID 17)
    - Audio(PID 192 ID 18)

When in fact the first stream is video, which you can see the program knows from the fact that it is using PES ID 224 (0xE0).

The output stream appears to correctly identify the video as MPEG-4 video, its just the information in the panel that is wrong.

In the demux panel if I set set the output for the video to REMOVE_ALL_MESSAGE.m2v, and that file exists, it will ask me if I want to replace it.  I say yes, but then it creates REMOVE_ALL_MESSAGE.m2v.mpg instead.  The original file REMOVE_ALL_MESSAGE.m2v is not replaced.  

If I add an extension to the output file, you shouldn't add the .mpg to the end as well.

I'm in the mux panel.  I add an h.264 elementary stream.  The preview panel will now allow me to watch the video if I want.  However, if I hit play, the slider will run into the right hand side quite quickly, in about 14 seconds.  The sample is 15:00 minutes long though.  When it gets to the right side the video will continue playing (I think it stops in the remux window oddly enough).  Although the slider is already at the right end, you can reposition it and it will correctly position the player in the stream, and allow you to play from there, however it will hit the right hand side again in about 14 more seconds.

I have a transport stream, encoded by XMuxer Pro from an h.264 elementary stream and an MPEG-1 audio elementary stream.  It is 2Mbps and 15:00 minutes long.  When I open in it Elecard MPEG Player (4.0.57 build 51117) the video plays fine, but the slider advances to the right very quickly, and runs into the right hand side at 19.7 seconds.  A number of the controls (pause, fast-forward) then become unusable.  If I move the slider, it only allows access to the first 19.7 seconds.  You can leave it playing, and it will play past this point, but the controls and slider are unusable.

FYI: The h.264 es is from Ateme's h.264 encoder (which is very good by the way).  If I look at the stream info for the video stream it is a little funky.  It says the BitRate is 91 201 664, whatever that means.  In reality its a little under 1.5Mbps.  Is this the cause of the problem?  Not sure.  The sample is NTSC, progressive.  

I can upload a chunk if you like.  Would have to figure out how much is needed.  Hopefully it would reproduce in 30 seconds or so.

To change the program number simply right click on the Program in the right pane and selecting "Program Number".  Then type in the new number.

I don't think there's any way to change the TSID.

I took an AVC transport stream I had that I created with Ateme's Encoder.  2Mbps transport bit rate.  Plays fine on my Amino AmiNet 124 STB and with Elecard's player on Windows.

I demuxed it using Xmuxer Pro 2.0 (downloaded and installed today (.exe is 2.0.60530).  I also have the AVC plugin (1.2.60502) installed.  Produced two files--one I called REMOVE_ALL_MESSAGE.m2v and one I called REMOVE_ALL_MESSAGE.mpa.  The first is presumably the h.264 elementary stream.  The second is the MPEG-1 audio stream.

I then attempted to mux the two elementary streams together to create a new transport stream.  I told it to pad (I want CBR), I set the bit rate to 2000000 (the same as the original), set the output file, and hit Start.  The program creates the target file but then nothing.  The progress bar doesn't update, the file is zero bytes, and that's all.  You can close it by clicking on the X.

I tried setting the bit rate to 3000000 and got the same result.  Nothing is happening.

Doing the same thing earlier with MPEG-2 video & AC-3 audio worked fine.

I can upload a sample if you like, its quite short.