Moderator Control Panel ]

About SAT>IP discuss

Anything from the case design to the chip inside, from expectation to suggestion, the most important thing is, you are IN.

About SAT>IP discuss

Postby steven » Fri Jun 28, 2013 4:56 pm

Hi all

We found that SAT>IP is a good solution for home entertainment use, Which is a good solution for
MOI Streaming BOX too,but we have not enough information with this.

So we send this topic here, If someone have some information about this or You know how to do it
with our MOI Streaming BOX,we will appreciate if you can contact us with support#tbsdtv.com :)

If you have some ideal about SAT>IP , you can post it here too. :)

Here is some information :
http://en.wikipedia.org/wiki/Sat-IP
http://www.satip.info/sites/satip/files ... on_1_2.pdf


Kind Regards

steven
steven
 
Posts: 2058
Joined: Fri Aug 06, 2010 3:23 pm

Re: About SAT>IP discuss

Postby crazycat » Mon Jul 01, 2013 6:22 am

Protocol similar to HTSP used in TVHeadend.
crazycat
 
Posts: 463
Joined: Mon Jan 31, 2011 2:46 am
Location: Ukraine, Kharkov

Re: About SAT>IP discuss

Postby steven » Fri Jul 05, 2013 2:42 pm

Hi Crazycat

Thanks for your reply.
Yea,Just like the TVheadend's, but we do not know how to do in our MOI box to support the SAT>IP. :roll:

Thanks

Kind Regards

steven
steven
 
Posts: 2058
Joined: Fri Aug 06, 2010 3:23 pm

Re: About SAT>IP discuss

Postby linuxstb » Fri Jul 05, 2013 3:53 pm

No, SAT>IP couldn't be more different from tvheadend's HTSP protocol. I've briefly read that specificication, and all it seems to do is to provide remote access to DVB tuners. i.e. it is extremely low-level, meaning all channel scanning, configuration etc needs to be done on every client (if I understand correctly).

On the other hand, HTSP deals with high-level concepts such as demuxed audio and video streams, EPG data, channel lists etc. All these are configured once on the tvheadend server and then made available to clients.

There's nothing to stop anyone implementing SAT>IP for the MOI, but I think I can safely say that this is not something that is very likely to be added into tvheadend. At least, none of the existing developers would be interested in doing it.
linuxstb
 
Posts: 7
Joined: Wed Mar 27, 2013 8:03 pm

Re: About SAT>IP discuss

Postby gfi » Mon Jul 08, 2013 7:06 pm

steven
I wrote to You about SAT>IP by email.
Simulation of rtsp protocol, used by Sat>IP devices, isn't a problem.
Device can working with other tools simultanously.
That's mean, if frontend is busy by other applcation, device send message about busy, etc.

But:
Sat>IP working with principe one user -> one tuner. I don't know it's better or not. For little devices like MOI maybe better, due to lover CPU usage is needed.
But, it's always possible to start 2x TVheadend (one user -> one tuner).
I don't know, but I still think, is better to have a clear m3u playlist (and using xmltv for other apps) in PC or XBMC frondend.

For support of CI slot.
I'm working about month on upgrade of TVheadend to be PROPERLY handling of CI slot. There's a big problems and I think, never be working as is needed as sure. Lost time.
Better way for TBS - contact author of dvblink server. He can adapt it to MOI as sure.... Users can select TVheadend or DVBlink at start on webif of moi. Or just adapt first tuner for DVBlink, second for TVHeadend.

Back to Sat>IP.
---------------------
What I know, devices using linux based on STapi, insted (much better solution for us) DVBApi.
Max. 4 users. Of course, theres also posibility of use multicast, but...
It's only my opinion, I always prefer clear http or udp link instead communication protocol and only some SW and HW players.
Url I can adapt to all devices, SW players and EPG I have for free (xmltv). If isn't public xmltv for some countries, parser of EIT is available... Again, It's only my opinion.

But, If is that priority for You (I mean Sat>IP), I can buy one in Germany and help You. Let me know.
Without real device and experience, how is this stable, what clients working properly, etc, we can do nothing.
If You want playing with SAT>IP protocol, You can adapt it with tools in attachment. Tune, sending pids array by tcp, etc.

I agree with linuxstb, I don't think, Sat>IP is any miracle. It's really only low level. Decoding (what I know, but I'm not sure), muxing, epg parsing begin on client side.
Practically Sat>IP only tune and resending pids array stream as begin.
----------------------------

What is more important - tune chipset to finally state.

In case of MOI also expanding of USB efficienty to max.
If will be possible to setting HW pid filtering in the future, partly problems can be solved (depending of tuner options).
I think, nobody need all channels from 1 TP, now is opened all TP, not important, If You need only 1 channel (of course I think load to USB and also CPU, not in dvr).
Max. efficiency of USB in MOI (8 devices connected!) for tuners is max. 15-20% (~90M).
So, If user opening TP with 8PSK modulation and 30M Symbol Rate, will be have problem with second adapter as sure. And there's no important, how is opened dvr and demux. Need to say, this is problem with all devices like that.
Next and finally: define timeout to be tuner going to sleep after close handle. Option in TVheadend for close handle in idle state don't working with MOI.

Also to DVR in MOI, I wrote about that 5x. For find a max. possibilities is need precompile driver with value of DVR_BUFFER *16 (!) and put upgraded kernel source into Your site. I've tool, what give me a real value of max. usage for both tuners (there's also CPU and USB high load...). Default value in dmxdev.h is for One tuner, also older kernel is used...
Or, maybe better solution, make kernel and rootfs in udev, instead mdev and compile dvbcore and other modules (also MOI tuner) with last media build of v4l. Higher value of DVR buffer is needed too.

I tried change kernel to be dynamically assigned device for create udev rootfs, but I'm ending with MISHMASH in compilation.

I've updated buffer to default value *4, software PID filtering and look at pictures for real CPU load. But there's still problem, tuner driver is preconpiled with default value, so I can adapt it with calculation, only. In this case, MTV Live HD on 13E with CI (11M bitrate), http stream (picture).
On other channels I have much higher CPU load, or I need change buffer values. So, we need to find a max. possibilities for create any basic FAQ for streaming and used tools in MOI. I'm still waiting for final kernel with upgraded values, now I can't do nothing.

Again, If You strictly need SAT>IP, let me know by PM and I buy one device.
Will see, how working. I think, that haven't future. I realy don't know, how it be working (decoding) on Android/Apple devices. But, some devices using STi7126, what have HW support of CSA decryption, oscam exist also for STAPI, other tools too... Missing detailed informations on internet.
Without real device and experience, how is this stable, which clients working properly, etc, we can do nothing.
Attachments
MOI+cam_load.jpg
gfi
 
Posts: 114
Joined: Tue Mar 05, 2013 10:55 pm

Re: About SAT>IP discuss

Postby gfi » Mon Jul 08, 2013 7:18 pm

If You want playing with SAT>IP protocol, You can adapt it with tools in attachment. Tune, sending pids array by http, etc.
Attachments
tuner-tools.zip
(226.58 KiB) Downloaded 336 times
gfi
 
Posts: 114
Joined: Tue Mar 05, 2013 10:55 pm

Re: About SAT>IP discuss

Postby steven » Thu Jul 11, 2013 11:56 am

Hi gfi

Really thanks for your reply and the information you give to us. :)

We will try the tools you send to us. and send the test report to you later.

And i agree with you that we need to buy one SAT>IP device to have a check
how it work. :)

Kind Regards

steven
steven
 
Posts: 2058
Joined: Fri Aug 06, 2010 3:23 pm

Re: About SAT>IP discuss

Postby cody » Fri Jul 12, 2013 1:41 am

gfi Wrote:...is need precompile driver with value of DVR_BUFFER *16 (!)...Higher value of DVR buffer is needed too.


correct me if i'm wrong and misunderstand what you mean, but isn't default DVR buffer size set and changed from the application side via DMX_SET_BUFFER_SIZE ioctl without any need of rebuilding the kernel and the drivers, for example:

#define DVR_BUFFER_SIZE 100*188*1024 /* bytes */
int fd_dvr = 0;
char *fn = "/dev/dvb/adapter0/dvr0";

fd_dvr = open(fn, O_RDWR | O_NONBLOCK, 0);

ioctl(fd_dvr DMX_SET_BUFFER_SIZE, DVR_BUFFER_SIZE );

and what's defined in 'dmxdev.h' is just the default size.
cody
 
Posts: 627
Joined: Tue Apr 13, 2010 11:20 pm

Re: About SAT>IP discuss

Postby gfi » Sat Jul 13, 2013 12:01 pm

cody Wrote:
gfi Wrote:...is need precompile driver with value of DVR_BUFFER *16 (!)...Higher value of DVR buffer is needed too.


correct me if i'm wrong and misunderstand what you mean, but isn't default DVR buffer size set and changed from the application side via DMX_SET_BUFFER_SIZE ioctl without any need of rebuilding the kernel and the drivers, for example:

#define DVR_BUFFER_SIZE 100*188*1024 /* bytes */
int fd_dvr = 0;
char *fn = "/dev/dvb/adapter0/dvr0";

fd_dvr = open(fn, O_RDWR | O_NONBLOCK, 0);

ioctl(fd_dvr DMX_SET_BUFFER_SIZE, DVR_BUFFER_SIZE );

and what's defined in 'dmxdev.h' is just the default size.


Yes, it depend, how is created application.
But, as I wrote, isn't important, how is dvr and demux opened. I still getting some limits from MOI (check it by yourself). And then comming EOVERFLOW from dvr_read in second adapter.

With this method I can't find limits.
This is more difficult, for example Astra have some method for setting of buffer. In some cases (boards) that working perfectly, on other has no effect.

Try open full TP (any lower and only to dvr) and change values. If You're going to higher TPs, You can find a limits, or You can't doing with second adapter nothing.
It's normal, but I thing, limit is low. And can be higher, I think.
gfi
 
Posts: 114
Joined: Tue Mar 05, 2013 10:55 pm

Re: About SAT>IP discuss

Postby cody » Mon Jul 15, 2013 9:20 pm

@gfi

based on what you're saying, i believe you mean not so much the dvr buffer, which can be changed from application side, but more the buffer used for data transfer from the side of the driver - that depends not just on the driver, but as well on the usb-endpoint settings. anyway, i believe i get your point and i'm going to investigate in such direction, i.e. if it's possible with changing buffer size to improve the usb performance. i will keep you inform here - expect in few days to be able to tell you more.
cody
 
Posts: 627
Joined: Tue Apr 13, 2010 11:20 pm

Next

Return to General discussion

Who is online

Users browsing this forum: No registered users and 2 guests