Hi, I was doing some testing and multiplexing the same files encoded using MainConcept's H.264 Encoder V2, and Ateme's Digital Encoder 184.108.40.206.
The same file was used as source and I attempted to use the same settings for both encoders.
After that, I used XMuxer to multiplex each H.264 video file with Two other MPA audios in a single TS stream.
The videos duration was exactly 2 minutes, and while using MainConcepts encoder, the resulting TS file was OK. However, using Ateme's encoder posed a issue that took me quite some time to figure out. Depending on which encoding configurations were chosen, the final TS file produced by XMuxer would have 2'05" , 2'15", and so on...
There were times when the XMuxer app would freeze after pressing the "Start" button and I would have to close the app and open it again. There were times when I would open the application after a freeze situation like the one described above, and not even the files I used before would work again.
So all in all, it was a pretty weird situation.
One of the things I found out at first, was that by changing the Slice mode in the video encode settings inside Ateme, it would change the way the final TS file multiplexed by XMuxer would behave.
I then tryed to use the Graphedit application in order to create files in a way similar to XMuxer, because Xmuxer was hanging way to often.
Then after setting all the configurations, I used the same video produced with Slice 1, and Slice 2 modes. These pictures below show the results for Slice 1 mode after they are muxed by MainConcept multiplexer.
And these are the results when the Slice 2 mode was used...
So, You can see that the final duration for the file using Slice Mode 2 is different.
In Ateme's manual, the Slice mode is something used to speed up encoding by splitting the frame among different cores (and as my machine uses two dual core Xeon processores, this makes for a big difference at the encoding time)...
The padding packets are also different, but I guess this is due to the fact that the two files are identified as having bigger and lower bitrates at the input (although the same bitrate was chosen when encoding with Ateme).
Could this be an effect of the Elecard MPEG Demultiplexer prior to Multiplexing process? Ir this might be an incompatibility with XMuxer and Ateme?