search

versatica / mediasoup

Cutting Edge WebRTC Video Conferencing
https://mediasoup.org
ISC License
6.12k stars 1.12k forks source link

Roadmap for mediasoup v3 #227

Closed ibc closed 5 years ago

ibc commented 5 years ago

After internal discussions we have decided to start the design of the future mediasoup v3. The v2 version has been a great advance and had made possible many scenarios that were impossible in v1 (it introduced mediasoup-client which provides a proper and unified API for all the browsers). However we are aware of a big room for improvement in the current v2 design.

Changes for v3 and their rationale

tkmn0 commented 5 years ago

Hi! Thanks for good news about mediasoup v3. I have a question. How about native mobile client? if "real JS API" supports native client as well, it is good however, if not, should we use react native SDK live mediasoup v2?
Actually, I'm looking for SFU media server which can handle offer from native mobile clients.

Best regards.

xxxman2008 commented 5 years ago

hi，guys， from jssip and now mediasoup，you did great job.

i have no idea with the roadmap. i'm using kurento now. i really want to use mediasoup instead,because nodejs seems friendly for me.and mediasoup seems more stable than kurento. but,theres something i really not like. mediasoup client using (or almost force to using) your signal server. i agree it make things simple. but i like socket.io as signal server. just personal choice.

second, i choose kurento ,because i need some CV(computer vision) function. it make technoligy meanable. if we just want VC, theres dozens solution . infact i don't think google can make webrtc project right.it seems someday,they have an idea,and say let's do it. so many "maybe change" api,behavior in the webrtc project.

so,i don't think "improve performence" in V3 is important. to be honest ,who will use nodejs do a heavy job? and,if we talk VC, the biggest problem is bandwidth.before we exceed mediasoup performance limit, the bandwidth or udp package crash the server 99999999 times.

personally, i want mediasoup has more function, can export "stream/rtp" object /data ... etc.but,it is your project, you are the god.

ibc commented 5 years ago

I have a question. How about native mobile client? if "real JS API" supports native client as well, it is good however, if not, should we use react native SDK live mediasoup v2?

There is an open issue for this: https://github.com/versatica/mediasoup-client/issues/6

However, we have not received any contribution. Building a native SDK requires time and expertise. We, the mediasoup developers, can rely on react-native-webrtc (even if ugly) for now, but it requires a JS client (in this case React Native) which is not the only choice when it comes to build mobile apps. We agree that a proper C++ mediasoup-client-native with bindings for Android and iOS would be great, but we need help on this or someone who pay us for coding it.

I wrote libsdptransform, which is a C++ port of the sdp-transform JS library (internally used by mediasoup-client) but more pieces are needed to create mediasoup-client-native.

ibc commented 5 years ago

mediasoup client using (or almost force to using) your signal server. i agree it make things simple. but i like socket.io as signal server. just personal choice.

This si completely false. We've NEVER recommended using ANY signaling protocol. The documentation clearly says that mediasoup does not mandate any sig protocol, and there is even a Examples section with mediasoup examples using different signaling solutions:

https://mediasoup.org/documentation/examples/

so,i don't think "improve performence" in V3 is important. to be honest ,who will use nodejs do a heavy job?

No idea. May be Netflix? PayPal? are those good examples of applications running on top of Node that also require a very good performance?

BTW mediasoup exposes its API in Node but it manages audio/video in C/C++.

and,if we talk VC, the biggest problem is bandwidth.before we exceed mediasoup performance limit, the bandwidth or udp package crash the server 99999999 times.

Bandwidth is not a problem if you can run parallel servers. That's one of the features that mediasoup v2 will enable.

personally, i want mediasoup has more function, can export "stream/rtp" object /data ... etc.but,it is your project, you are the god.

You are welcome to propose those features you wish. Have you requested them before?

notedit commented 5 years ago

This works very well for some hundreds of participants, but it does not scale well for broadcasting scenarios (a few media producers and many many many consumers)

In this case, how the producer side handle PLI/FIR ? If we have several consumers has very poor network, there will be many PLI/FIR requests I think.

xxxman2008 commented 5 years ago

hi, ibc , take easy .

I read the whole document about mediasoup . I know mediasoup "NEVER recommended using ANY signaling protocol." . But ,in real life ,if somebody want his project online ASAP, it's better to using "Pxxx server". i forgot the name. So it 's why i said "force to using" ..maybe ,i should say " for lazy man". haha.

I applaud mediasoup exposes its API in Node but it manages audio/video in C/C++. It's a good design. In fact, i have test using pure nodejs to proceed "media stream regarding" task. such as RTMP /FLV. You know the result. That's why i say "who will use nodejs do a heavy job".

Have you requested them before? --- OK , i just told you yesterday ..hahah. from my post ,you know my english is poor. so , usually , i will not say much.

Regarding the "bandwidth" , it's a huge topic. From my experience, in following scenario. 10 people Video conference ,every body publish 1280x720@25/30fps (720p) , 1M bps bitrate,CBR in SFU mode, One "server side" peer require bandwidth : 1 inbound stream: 1M bps ( let's say ,this number is min require for user experience ) 9 outbound stream : 9x1M bps So, the total bandwidth for one "server side peer" is 9M bps(out). 10 people should require 10x9M = 90M bps out . For a server have 1G bps Internet line , in above scenario, 100 people will consume the whole internat bandwidth. ( In real life ,we also should consider PPS(package per second) , "real time audio/video" ...etc. ). That's why i say "before we reach the performance bottle.....". You can not expect distributed design will resolve this problem . And in MCU mode , transcode CPU usage is the bottle. also not the mediasoup business. Maybe , netfix server equiped 10G NIC (and direct int ernet link),but i don't think mediasoup cann't handle it. That's why i say " the performance is not most important task for V3".

Just my opinion , V2 and mediasoup-client is enough for application development. It's time to make it stable , provide more function/api . for example : 1 - Integrate/plugin for "SIP" cooperation( so ,if boss have no internet access ,he can join the meeting via PSTN ). 2 - Integrate OpenCV or filter function or mixer function , so , the user can do some funny job with rtp stream .

BTW: i really really want to say "you do a good job". sincerely .

ibc commented 5 years ago

This works very well for some hundreds of participants, but it does not scale well for broadcasting scenarios (a few media producers and many many many consumers)

In this case, how the producer side handle PLI/FIR ? If we have several consumers has very poor network, there will be many PLI/FIR requests I think.

Currently the Producer.cpp class in mediasoup server already limits the number of PLI/FIR sent to the client. Basically, no more than 1 PLI/FIR per second is sent. If another PLI/FIR is requested in the meanwhile, it's delayed.

Said that, there is a simple rule here: just the encoder can process a PLI/FIR and generate the corresponding keyframe. So, when in a SFU scenario, that is the remote client.

ibc commented 5 years ago

I read the whole document about mediasoup . I know mediasoup "NEVER recommended using ANY signaling protocol." . But ,in real life ,if somebody want his project online ASAP, it's better to using "Pxxx server". i forgot the name. So it 's why i said "force to using" ..maybe ,i should say " for lazy man". haha.

The API documentation does not even mention protoo, so what you mean is the mediasoup-demo project (which indeed uses protoo as signaling protocol).

I applaud mediasoup exposes its API in Node but it manages audio/video in C/C++. It's a good design. In fact, i have test using pure nodejs to proceed "media stream regarding" task. such as RTMP /FLV. You know the result. That's why i say "who will use nodejs do a heavy job".

What we (also) want to promote in mediasoup v3 is the ability to create server-side media producers that inject streams into a mediasoup instance. Those producers may run in the same or in different server. And we'll try to make it easier to develop those producers in any language.

For a server have 1G bps Internet line , in above scenario, 100 people will consume the whole internat bandwidth. ( In real life ,we also should consider PPS(package per second) , "real time audio/video" ...etc. ). That's why i say "before we reach the performance bottle.....". You can not expect distributed design will resolve this problem .

The fact that 20 participants are sending a video stream to mediasoup does not mean that mediasoup is forwarding 20-1 streams to each participant. It's up to the application to decide which streams are sent and which one are not in each instant. For example, if your app UI just renders 10 remote videos, your JS may pause all the others and resume them when they become "visible".

And in MCU mode , transcode CPU usage is the bottle. also not the mediasoup business. Maybe , netfix server equiped 10G NIC (and direct int ernet link),but i don't think mediasoup cann't handle it. That's why i say " the performance is not most important task for V3".

Performance is not the only reason for v3. If you read the 4 bullets above, just one of them talks about "performance".

Just my opinion , V2 and mediasoup-client is enough for application development. It's time to make it stable , provide more function/api . for example : 1 - Integrate/plugin for "SIP" cooperation( so ,if boss have no internet access ,he can join the meeting via PSTN ).

We want to keep mediasoup as simple and small as possible. We don't want to create a full monster that does everything. One of our goals in v3 is allow developers to easily plug their own stuff into mediasoup.

2 - Integrate OpenCV or filter function or mixer function , so , the user can do some funny job with rtp stream .

OpenCV does not fit well within a SFU. A SFU receives, selects and forwards streams, "just that". If you want to do computer vision or AI or whatever, you need a "media server". What we want to allow in mediasoup v3 is making it easy for developers to plug those "media servers" into mediasoup (in the same or in different servers).

BTW: i really really want to say "you do a good job". sincerely .

Thanks a lot.

xxxman2008 commented 5 years ago

What we (also) want to promote in mediasoup v3 is the ability to create server-side media producers that inject streams into a mediasoup instance. Those producers may run in the same or in different server. And we'll try to make it easier to develop those producers in any language.

That's ok . Do you mean anyone using mediasoup can take streams out , do some job ,and then put it back?? or , insert/replace streams into "server side peer" ?

Anyway ,these ideas is great. So, the filter/mixer/CV/AI can be true. up to application developer.

ibc commented 5 years ago

Do you mean anyone using mediasoup can take streams out , do some job ,and then put it back?? or , insert/replace streams into "server side peer" ?

It's not mediasoup the entity who will do such as "job". The picture would be as follows:

Flamenco commented 5 years ago

Just piping in my 2 cents here, but I would like to add some thoughts to the V3 horizon.

I started using Mediasoup because I wanted to broadcast from a browser. I had 3 choices for architecture: mesh, peer-to-peer downstream distribution, and server based. Because I also wanted to record all streams on the server, Mediasoup was the best choice. I really liked it's simple and universal API on the client, and ability to run without installing a separate server daemon. Furthermore, the node wrapper around a C-based core installs seamlessly. If I had any other use-case, I would not have gone with Mediasoup.

I am happy to see that the 'broadcast' use case is high on the priorities! What I do not understand is the discussion around the limiting factor when broadcasting. It seems to me that the focus should be on running multiple instances of MediaSoup on multiple networks to scale horizontally. No matter how much we refactor and/or streamline the API, the biggest issue when it comes to broadcasting will always be performance on production systems.

So I would like to see a system to easily create, configure, and monitor a network Mediasoup servers that provides load-balancing and fault tolerance.

ibc commented 5 years ago

@Flamenco:

It seems to me that the focus should be on running multiple instances of MediaSoup on multiple networks to scale horizontally.

Please re-read bullet 4 in the issue description. mediasoup v2 uses N C++ subprocesses, but each room just runs in a single subprocess, so before "scaling horizontally" it would be simpler to just scale within the same machine by allowing a room to use N C++ subprocesses.

mediasoup v3 will allow that and also horizontal scaling via separate servers.

No matter how much we refactor and/or streamline the API, the biggest issue when it comes to broadcasting will always be performance on production systems.

The API refactor has a different motivation. The 4 bullets above do not have direct relationship between them, they are orthogonal features/changes.

Flamenco commented 5 years ago

Hello @ibc. Thank you for responding. I did read bullet #4. My issue is that my bandwidth, not my CPU, is the limiting factor. Once my application has a certain number of (publishers x subscribers), I will need to run on another physical network. On my LAN, I have 8 servers, each with 12 CPUs and 100 GB RAM. No matter how much you optimize your code, my WAN network is the limiting factor.

The API refactor has a different motivation

That's my concern. I was hoping we could consider all the options before you start your journey.

mediasoup v3 will allow that and also horizontal scaling via separate servers

I don't see this 'horizontal scaling' in the original post or anywhere else for that matter.. If that's the case, great!

ibc commented 5 years ago

We cannot do magic to increase WAN network bandwidth. However streaming servers do exist. I assume they solve the network issue somehow.

ibc commented 5 years ago

I hope this will help people here understand the motivation for the new broadcasting design in v3:

https://github.com/versatica/mediasoup/blob/master/doc/Charts.md

ibc commented 5 years ago

@notedit, please take a look to the issue description, I've updated it with info about "PLIs every two seconds".

ibc commented 5 years ago

For all those interested in how the v3 API will look like, here a test unit that makes use of all the API in mediasoup-client v3:

https://github.com/versatica/mediasoup-client/blob/master/test/test.js?ts=3

yarekc commented 5 years ago

please don't make a protoo/reactjs gas factory for demo. Provide some simple : pubsihStream(streamid) and playStream(streamid) function that will fit 99% of all developers needs !

ibc commented 5 years ago

There are already N mediasoup example apps running vanilla JS. Please don't reopen such a request here again.

yarekc commented 5 years ago

I am not asking for example apps. I am happy some users added finally some samples. I am asking for 2 functions that will make it even easier to be used. When using flashphoner, antmedia, red5pro or wowza people handle 3 functions: publish, play, record

ibc commented 5 years ago

I am asking for 2 functions that will make it even easier to be used.

This is the API in mediasoup-client v3.

When using flashphoner, antmedia, red5pro or wowza people handle 3 functions: publish, play, record

You can use them if you are fine with the API they expose. mediasoup will be as low level API as possible to allow any kind of scenario (meetings, broadcasting, etc).

Also, those apps you mention provide a specific signaling protocol, mediasoup does not.

ibc commented 5 years ago

When using flashphoner, antmedia, red5pro or wowza people handle 3 functions: publish, play, record

In mediasoup-client v3:

// Send a track.
const audioProducer = await sendTransport.send({ track });

// Receive a track.
const audioConsumer = await recvTransport.receive({ producerId });

// Play the received track into an HTML <audio> element.
audioElem.srcObject = new MediaStream([ audioConsumer.track ]);

And, of course, communicate those actions (when appropriate) to the server to call mediasoup server API methods on the corresponding entity (Transport, Producer, etc).

yarekc commented 5 years ago

that's brilliant. If could could embed that into you demo, that would be perfect. Ex: how to get the producerId in the recvTransport or set it on sendTransport. Thanks again.

ibc commented 5 years ago

Ex: how to get the producerId in the recvTransport or set it on sendTransport.

That will be documented once mediasoup (server) v3 is done :)

yarekc commented 5 years ago

Thanks IBC,

Do you have an idea when v3 will be online ? Do you plan to create this Faq:

ibc commented 5 years ago

Well, you talk like if mediasoup V2 documentation did not explain how to publish a stream, doesn't it?

Anyway, mediasoup does not manage streams (MediaStream instances) but tracks (MediaStreamTrack instances). Hope that's not a problem.

ibc commented 5 years ago

For those who would like to know how to use ffmpeg in mediasoup v3 to send (for example) and audio file, take a look to this.

mpbikc commented 5 years ago

And how long we shourl wait for v3 version? I see, you have started. But when we will see first release - it is 1 month, or may be half year? As for me I wanted to migrate from kurento to mediasoup but faced with 2 big problems. I think most of developers will face with them(yarekc, me - are examples):

1) I read all mailing lists, all documentation, but couldn't find good way to record video. I created RtpStreamer( via room.createRtpStreamer(producer, {..... And then I tryed to use ffmpeg, like

v=0 o=mediasoup 7199daf55e496b370e36cd1d25b1ef5b9dff6858 0 IN IP4 127.0.0.1 s=7199daf55e496b370e36cd1d25b1ef5b9dff6858 c=IN IP4 127.0.0.1 t=0 0 m=video 20000 RTP/AVP 101 a=rtpmap:101 H264/90000 a=sendrecv

ffmpeg -protocol_whitelist "file,rtp,udp" -vcodec h264 -re -i video_sdp -vcodec copy video_out.mp4

And the same for opsus video, but audio and video were not synchronized and I don't know how automatically do it.

I tryed gstreamer - it worked better:

gst-launch-1.5 -em \
  rtpbin name=rtpbin latency=5 \
  udpsrc port=20002 caps="application/x-rtp,media=(string)audio,clock-rate=(int)48000,encoding-name=(string)OPUS" ! rtpbin.recv_rtp_sink_0 \
    rtpbin. ! queue ! rtpopusdepay ! opusdec ! audioconvert ! audioresample ! voaacenc ! mux. \
  udpsrc port=20000 caps="application/x-rtp,media=(string)video,clock-rate=(int)90000,encoding-name=(string)H264" ! rtpbin.recv_rtp_sink_1 \
    rtpbin. ! queue ! rtph264depay ! h264parse ! mux. \
  flvmux name=mux streamable=true ! filesink location=/home/oracle/test/q1.mp4

Sometimes video and audio were synced, but sometimes not. Also that convertation eats about 5% of CPU. So If I want to record with gstreamer - I'll can support few streams on one machine. And As i noticed - record is not stable.

I undertand, that mediasoup is just base platform, but if you will write any example how with createRtpStreamer create stable record - huge number of developers wil say you 'THANKS!!!'

2) The second problem - I could'n find way how to translate streams via RTP from one ms to another. In last example for v3 you talked how with createPlainTransport do that, but in version 2 documentation dont explain that.

Without 2 that things no large product can be created with mediasoup,thow it works great for just retranslating streams.

I hope you will listen to that and create some howto(or best practive) with most important things for v3.

ibc commented 5 years ago

And how long we shourl wait for v3 version? I see, you have started. But when we will see first release - it is 1 month, or may be half year?

We want to have a first v3 version for end of January, but cannot provide a specific ETA.

I read all mailing lists, all documentation, but couldn't find good way to record video.

The RtpStreamer class will be removed in v3. At the end, in v2 it's just a Consumer plus a plain RtpTransport that can just be used to broadcast a specific Producer to a plain RTP remote endpoint.

In v3, the Node app will be able to create any kind of transports (WebRTC or plain RTP) and use them to broadcast N producers to a remote endpoint, but will be also able to inject external RTP into that transport and generate M `producers.

I don't think ffmpeg is good to save both audio and video. AFAIK it has a very poor RTCP support (no NACK support for instance). I expect gstreamer to be much better. However in v2, and as you posted in your comment, two different transports are required. In v3 you'll be able to bind gstreamer in a single port to receive both audio and video (assuming gstreamer supports it). That may help. You may also want to try the new gst-plugins-bad-plugins-webrtcbin.

The second problem - I could'n find way how to translate streams via RTP from one ms to another. In last example for v3 you talked how with createPlainTransport do that, but in version 2 documentation dont explain that.

Well, that's because it's a feature for v3 :) It will be documented when done.

havfo commented 5 years ago

Great work on v3 so far!

In our project we plan on having a hybrid peer-2-peer and SFU mode, and the new architecture seems to make this much easier. We have a, so far, unpublished fork of mediasoup-client rewritten for peer-2-peer, but it is not very elegant to use two libraries together that handle everything up to and including Room level.

ibc commented 5 years ago

In our project we plan on having a hybrid peer-2-peer and SFU mode

The v3 API will be much more minimalist (no peers, no artificial events, etc). Since mediasoup does not mandate a specific signaling protocol, the application must provide one to communicate the client with the server. Whether you invoke mediasoup server methods or just carry your own P2P sig messages is up to the app. I think that's the correct way to go.

havfo commented 5 years ago

Yes, we use socket.io at the moment, and for peer-2-peer, the messages are passed directly to the other peer(s). So our mediasoup-client fork is talking to itself on the other side.

virtualfunction commented 5 years ago

Just out of curiosity, is the mediasoup-client v3 package being developed in sync with the server v3 changes (i.e. does the client rely on cutting edge server code, or will it run on the latest stable version of the server?)

ibc commented 5 years ago

mediasoup-client v3 will just work with mediasoup v3.

Anyway v3 drops the "MEDIASOUP_PROTOCOL" so there isn't so much dependency between client and server anymore. In fact, in v3 it will be possible to publish media into the server without using mediasoup-client, for example using ffmpeg: https://github.com/versatica/mediasoup/blob/master/doc/ffmpeg.md

virtualfunction commented 5 years ago

OK, that makes sense. Out of curiosity, what's sort of ball-park / estimated time frames do you have in mind here?

I'm fairly new to MediaSoup, but dabbled with Kurento a while back only to find the development has ground to a halt. So it's nice/reassuring to see a project like this where there's lots of activity.

The reason I ask about time frames is that I'm trying to assert if I develop something against v2 knowing that I'll need to rewrite it when v3 comes out, as these appear to be significant design overhaul, or am I better to wait a bit but try and develop against the bleeding edge v3 release and save myself a few rewriting chores later on. It looks like v2 provides a number of high level abstractions / concepts (i.e. Rooms / Peers, etc) that will won't be there out of the box in v3. Obviously these abstractions seem to help with general use cases, but come at the cost of not always being as helpful for more niche use cases, and I'm guessing this is a motivating factor for this change.

I guess this goes on to another question that I'm sure others might also be thinking about... Do you think you'll be writing some sort of wrapper library that works with v3 that effectively allows for a more graceful transition?

On an unrelated note, the FFMPEG stuff looks great, it's just the sort of thing I'll be needing in due course as our broadcasting goes through a bit of pre-processing, so looking forward to this. From what I can infer, it looks like this will work with other media stacks like gstreamer too.

ibc commented 5 years ago

OK, that makes sense. Out of curiosity, what's sort of ball-park / estimated time frames do you have in mind here?

We want to have a preliminar v3 version ready during February.

The reason I ask about time frames is that I'm trying to assert if I develop something against v2 knowing that I'll need to rewrite it when v3 comes out, as these appear to be significant design overhaul, or am I better to wait a bit but try and develop against the bleeding edge v3 release and save myself a few rewriting chores later on. It looks like v2 provides a number of high level abstractions / concepts (i.e. Rooms / Peers, etc) that will won't be there out of the box in v3. Obviously these abstractions seem to help with general use cases, but come at the cost of not always being as helpful for more niche use cases, and I'm guessing this is a motivating factor for this change.

Since you perfectly got the motivation for v3 I encourage you to wait for it, yes.

I guess this goes on to another question that I'm sure others might also be thinking about... Do you think you'll be writing some sort of wrapper library that works with v3 that effectively allows for a more graceful transition?

IMHO it would be a super wrapper library for both client and server side. I don't think we'll do something like that. We'll try to focus on proper documentation (much better than now).

On an unrelated note, the FFMPEG stuff looks great, it's just the sort of thing I'll be needing in due course as our broadcasting goes through a bit of pre-processing, so looking forward to this. From what I can infer, it looks like this will work with other media stacks like gstreamer too.

Yes sure, as far as you can decide some RTP parameters such as codec name, payload type, ssrc, etc, you should be able to use any RTP stack to produce media into mediasoup v3.

virtualfunction commented 5 years ago

As well as API docs it would be good to see some conceptual higher level docs (along with migrating over). I see you've removed rooms and peers and it looks like Router takes its place. Whilst Kurento seems to have died off, I found the concept of just joining endpoints (likewise in Medooze) fairly intuitive, and the docs in Kurento are better than competing projects imo

ibc commented 5 years ago

We'll do big improvements in documentation for v3.

Globik commented 5 years ago

"And we'll try to make it easier to develop those producers in any language."

Please for C programming language too.

ibc commented 5 years ago

Too.

yarekc commented 5 years ago

hi, Any news about v3 availability ?

ibc commented 5 years ago

You can check the progress in the v3 branch of mediasoup, the master branch of mediasoup-client, and the v3 branch of the mediasoup-demo project.

ibc commented 5 years ago

Hi all. mediasoup v3 is close. We are refactoring the simulcast stuff. Everything else is working fine and the new API looks very nice (IMHO).

There is no yet API documentation. However, those interested in v3 may take a look to the new mediasoup-demo.

lakano commented 5 years ago

@ibc Thanks for your work! Do you have any idea of when the API v3 documentation could be available please? ( few days ? few weeks ?)

ibc commented 5 years ago

Let's say some weeks.

Globik commented 5 years ago

@lakano the idea is always there! But how to npm install mediasoup v3.0 on your computer?

ibc commented 5 years ago

But how to npm install mediasoup v3.0 on your computer?

There is no npm package yet...

denishacks commented 5 years ago

@lakano the idea is always there! But how to npm install mediasoup v3.0 on your computer?

{
    "mediasoup-client": "git://github.com/versatica/mediasoup-client.git#master"
}

See more https://docs.npmjs.com/files/package.json#dependencies

Globik commented 5 years ago

Hey, @ibc , it would be nice to have a demo part in vanilla js. In the whole the demo is great. Nice work. Sorry.

jmillan commented 5 years ago

Hey, @ibc , get rid of f**ing reactjs in your demo part. It's sck

@Globik, be original and build your own app instead of reusing a demo.