many could be the problems here.
the report is lacking some details!
the command sequence is very simple but there are various kind of "mis-understatement" here at logical and "physical" level..
let me note that "tscbrmuxer" miss a param after the o:10000000
tscbrmuxer b:5000000 prg1.ts b:5000000 prg2.ts o:10000000 >mux.ts &
usually you put in the end a "null.ts" TS packet file so the software tool "fills" the exit bitrate with null packets..
tscbrmuxer b:5000000 prg1.ts b:5000000 prg2.ts o:10000000 null.ts >mux.ts &
BTW the script should really stop here with some error message..
then there's a problem related to "flow control". the standard Opencaster technique is made out of "pull" packets from the end of the chain (the last line driver) in this case the tsudpsend" tool at CBR of 10Mbps.
the UDP packets from the source are coming anyway without back pressure control. they could fill the pipe and can't be stopped. are they CBR? and net latency?
usually to mix and match rates, when there are missing packets from one source you could use "tsorts" to feed anyway the downstream sink. this is not the case here..
lastly, the two source streams do both have a PAT on board and there's no filtering here. as they are brought out interleaved, the downstream decoder would surely get a hard time to understand which PAT is good and you'll get a lot of continuity counter error on PID 0 related to the mix of the two streams.
i'll not move along about the potential issues related to other well known packets (NIT SDT EIT etc..) as from the few notes you put in your requests, i understand you are not very knowledgeable about digital television technology, so i suggest you'll be better off with some more formal training before getting over this issue.
bests
Andrea
Login
Register
FAQ
Search
