<div dir="ltr"><div><div><div>Hi Trevor.<br><br></div>I would try using the following:<br><br><div style="margin-left:80px">.. ! queue ! chopmydata <b>max-size=1316 min-size=1316</b> ! udpsink ....<br></div><br></div>That works for me. Maybe you need to add do-timestamp to all your video sources as well.<br><br></div>P<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jun 16, 2015 at 7:22 PM, Clarke, Trevor <span dir="ltr"><<a href="mailto:tclarke@ball.com" target="_blank">tclarke@ball.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I've got an app that generates frames into multiple appsrc's, does some processing, encodes the frames to h.264 then muxes them all into an mpegts stream for transmission over udp multicast. Here's a summary of what it's doing (removed some custom plugins but they don't change caps):<br>
<br>
appsrc is-live=true -> videoconvert -> x264enc  bframes=0 tune=zerolatency bitrate=2500 byte-stream=true -> queue -> mux.<br>
appsrc is-live=true -> videoconvert -> x264enc  bframes=0 tune=zerolatency bitrate=2500 byte-stream=true -> queue -> mux.<br>
... 10 appsrc<br>
mux. is<br>
mpegtsmux ! tee name=split ! queue2 ! chopmydata max-size=32700 ! udpsink sync=true host=224.16.10.20 port=10000<br>
split. ! queue2 ! multifilesink sync=true location=... next-file=key-unit-event port-messages=true<br>
<br>
The x264enc is sometimes a custom nvenc wrapper. Mpegtsmux has been modified to include support for other metadata streams. But other than that, the above is a pretty close representation. The mpegtsmux is configured to set a different program for each stream. Some of the streams are VGA-ish sized, some are HD-ish sized, some are odd off-sized.<br>
<br>
The problem I have is when I push test patterns with black and white alternating bars, black and white alternating checkerboards, and similar patterns which compress a lot I'm seeing good playback performance on different machines (mac and windows, server on linux, mostly using vlc for playback)<br>
<br>
When I switch the test patterns to noisier data (randomized snow patterns) and the compression ratio drops I'm seeing significant playback issues to the point where is can take 30+ seconds just to see the program map show up in VLC and I get a couple of decoded frames per minute. Iftop on the server and client show that the raw packet throughput is roughly the same so I don't think I'm dropping packets. I ran ffprobe and ffplay on a mac client to see if it gave me any more information. Ffprobe shows a ton of errors:<br>
"decode_slice_header error"<br>
"non-existing PPS 0 referenced"<br>
"no frame!"<br>
<br>
This repeats for 15 seconds or so then I finally see the stream listing. Similar behavior in ffplay, lots of errors before syncing up to the stream then a frame here and there trickles through.<br>
<br>
Since I'm not dropping packets I'm thinking it might be a problem on the encoding side. Any thoughts?<br>
----------------------<br>
Trevor R.H. Clarke<br>
Software Engineer, Ball Aerospace<br>
(937)320-7087<br>
<br>
<br>
<br>
<br>
This message and any enclosures are intended only for the addressee.  Please<br>
notify the sender by email if you are not the intended recipient.  If you are<br>
not the intended recipient, you may not use, copy, disclose, or distribute this<br>
message or its contents or enclosures to any other person and any such actions<br>
may be unlawful.  Ball reserves the right to monitor and review all messages<br>
and enclosures sent to or from this email address.<br>
_______________________________________________<br>
gstreamer-devel mailing list<br>
<a href="mailto:gstreamer-devel@lists.freedesktop.org">gstreamer-devel@lists.freedesktop.org</a><br>
<a href="http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel" rel="noreferrer" target="_blank">http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel</a><br>
</blockquote></div><br></div>