Avalpa Community

The place where we can talk freely about Avalpa product and services
It is currently Wed Aug 17, 2022 1:27 pm

All times are UTC + 1 hour [ DST ]




Post new topic Reply to topic  [ 3 posts ] 
Author Message
PostPosted: Mon Jun 09, 2014 9:50 am 
Offline

Joined: Mon Jun 09, 2014 8:59 am
Posts: 1
Hi,

I have 2 UDP SPTS's

I need to create a MPTS with this 2 SPTS's and multicast the multiplexed MPTS to udp://239.255.2.1:1234

Here's what I did,
Code:
# mkfifo prg1.ts
# mkfifo prg2.ts
# mkfifo mux.ts
# tsudpreceive 239.255.1.1 1234 > prg1.ts &
# tsudpreceive 239.255.1.2 1234 > prg2.ts &
# tscbrmuxer b:5000000 prg1.ts b:5000000 prg2.ts o:10000000 >mux.ts &
# tsudpsend mux.ts 239.255.2.1 1234 10000000


But I can not get the multiplexed output at udp://239.255.2.1:1234

What did I do wrong ?

Please help.

Thanks.

euacreations


Top
 Profile  
 
PostPosted: Wed Jun 11, 2014 7:19 pm 
Offline

Joined: Wed Apr 16, 2014 11:02 am
Posts: 3
add a space before mux.ts ( > mux.ts )


Top
 Profile  
 
PostPosted: Wed Jun 18, 2014 12:49 pm 
Offline

Joined: Sun Sep 22, 2013 10:29 am
Posts: 39
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


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 3 posts ] 

All times are UTC + 1 hour [ DST ]


Who is online

Users browsing this forum: No registered users and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
cron
Powered by phpBB® Forum Software © phpBB Group