mpegtsmux problem

[Edward Hervey]

Hi,

  It's a bit hard to see what the root cause is (a full pipeline
description would help), but you should be aware that currently
mpegtsmux does not interleave the input.
  i.e. for each incoming buffer (which it decides is the "next" one
accross all input streams) it will entirely mux/push it before tackling
the next input buffer. If they all have the same PTS, it will pick them
at random, but still mux/push them one after the other, instead of
interleaving them.

  That being said, it shouldn't cause that much blocking. Are you
feeding the inputs (via appsrc) faster than the rate at which the output
is consumed ? Do you have queues before each mpegtsmux sink pads ?

   Edward


On Thu, 2015-05-28 at 20:46 +0000, Clarke, Trevor wrote:
> I'm attempting to mux a number of h.264 streams into an MPEG TS and write it to disk. I have a bin for each stream which generates the h.264 (data is pushed in via an appsrc, some processing occurs, and the compression is done by either a hardware plugin or x264enc).
> The src from each bin is fed into an mpegtsmux and the output goes to a tee with a multifilesink and udpsink.
> 
> I'm seeing the appsrc's buffers filling up a lot and I'm thus dropping packets regularly. I looked at the output files and generated timeline plots of the PTS values for each stream (testing with 3 in the example below). The streams are generated a 10fps and the caps for the h.264 streams represent this. Looking at the cache files I see the following (first line represents 0.1 second ticks, where the frames would ideally fall)
> 
> Ticks  |          |          |          |         |
> Str1   *                              *
> Str2                  *                                *
> Str3                           *
> 
> I'm seeing some expected jitter but it looks like the interleaving is putting 1 frame per tick across all streams not 1 frame per stream per tick. Thoughts on what might be causing this behavior?
> ----------------------
> Trevor R.H. Clarke
> Software Engineer, Ball Aerospace
> (937)320-7087
> 
> 
> 
> 
> This message and any enclosures are intended only for the addressee.  Please 
> notify the sender by email if you are not the intended recipient.  If you are 
> not the intended recipient, you may not use, copy, disclose, or distribute this 
> message or its contents or enclosures to any other person and any such actions 
> may be unlawful.  Ball reserves the right to monitor and review all messages 
> and enclosures sent to or from this email address.
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel