SDK Service Selection
At present, there are many services for live cloud broadcasting.
- Music as cloud
- NetEase cloud letter
- Poly vision
- Ali cloud
- Baidu Cloud
You can choose according to your own needs.
Basic Principles of Live Broadcasting
Push push flow
That is, the live broadcasting terminal, used for collecting video information upload, processing and so on.
Pull pull flow
Video Source Users Play Live Video in Real Time
Server side
Provide video storage, stream processing, compression, etc. Usually third-party services are used.
Let's take Lexus Cloud as an example
Account creation
Le Siyun Address
After registration, the user id and key are automatically generated. The parameters used in the later live push stream are the parameters.
If you want to create an activity, you need an identity authentication. After submitting the authentication information, you can contact the customer service for quick audit.
Then you create live broadcasting activities.
There are two kinds of Live Cloud Broadcasting services, one is Mobile Live Broadcasting, the other is Standard Live Broadcasting.
Asked the customer service, said that the difference between the two is that standard live broadcasting has management background. You can see the status of live broadcasting.
The parameters invoked by the two methods are also different.
After the console creates the activity, it automatically generates the playback address, copies the address to the browser and opens it. When it is in the push-flow state, it can see the live broadcast. Of course, you can also create activities through App, as will be mentioned later.
But there will be a delay of several seconds.
Integrate
The above live broadcasting uses the UI live broadcasting component provided by Lexus, including the switch of microphone, the adjustment of focal length, the degree and style of beauty, camera switching and so on.
Want to use requirements directly in the project Integrated SDK
The corresponding SDK can be selected according to the need.
Take Android as an example. After downloading, decompress and open the file to find LeRecorderSkin, import the file into the project as a model, and add dependencies.
Use
Two controls are provided in LeRecorderSkin.
Different controls initialize live broadcasting in different ways
1. Standard live broadcasting:
<?xml version="1.0" encoding="utf-8"?> <com.le.skin.LePublisherSkinView xmlns:android="http://schemas.android.com/apk/res/android" android:orientation="vertical" android:layout_width="match_parent" android:layout_height="match_parent" android:id="@+id/lpsv_stream_recorder"> </com.le.skin.LePublisherSkinView>
Initialization method
skinView.initPublish(userid, key, activityId);
2. Mobile Live Broadcasting:
- Push-flow function can be realized by splicing fields directly.
Push Rules: rtmp:/{Push Basin Name}/ Publish Point/{Live Stream Name}.
Play Rules: RTMP Protocol - rtmp:/{Play Domain Name}/ Publishing Point/{Live Stream Name}
HLS Protocol - http(s): //{Play Domain Name}/ Publishing Point/{Live Stream Name}/ desc.m3u8
HDL Protocol - http(s): //{Play Domain Name}/ Publishing Point/{Live Stream Name}.flv
<?xml version="1.0" encoding="utf-8"?> <com.le.skin.PublisherSkinView xmlns:android="http://schemas.android.com/apk/res/android" android:orientation="vertical" android:layout_width="match_parent" android:layout_height="match_parent" android:id="@+id/lpsv_stream_recorder"> </com.le.skin.PublisherSkinView>
Initialization method
skinView.initPublish(url);
Here you can complete the basic live function.
But if you want to expand more functions through App, such as modifying live broadcasting information, getting push address, etc. http requests are required.
Since controls exist in the introduced model, functions can be added or reduced on the original basis.
For example, in live broadcasting, title default display is active ID. If we want to change the name of the activity, first we need to parse the interface through network access, get the corresponding data, and then find the title Control in the layout.
Modify the initialization parameters and pass in the data that needs to be modified.
public void initPublish(String userId, String secretKey, String activityId,String name) { Log.d(TAG,"initPublish,Initialization"); this.userId = userId; this.secretKey = secretKey; this.activityId = activityId; if(TextUtils.isEmpty(skinParams.getTitle())){ nameView.setText(name); } LetvPublisher.init(activityId,userId,secretKey); publisher = LetvPublisher.getInstance(); super.initPublish(); }
Manual request activity
Standard Live Documentation
Manual requests require the use of a network access framework, where Retrofit 2.0 is used
Five fixed parameters need to be submitted before requesting any interface
The most problematic parameters are timestamp timestamp, and sign validation codes.
Most versions of ver are 4.0, and a few interfaces are 4.1, which can be obtained when viewing interface methods.
The method to get the timestamp is long timestamp = System.currentTimeMillis();
sign is a parameter after splicing and encrypted with md5.
Simply encapsulated network requests:
/* *Get the live push address * ver=4.0 */ public static void getPushUrl(String activityId,long timestamp,Callback<ResponseBody> callback){ String signSting = "activityId" + activityId + "method" + MyMethod.NAME_PushUrl + "timestamp" + timestamp + "userid" + MyMethod.userId + "ver" + MyMethod.VER4_0 + MyMethod.KEY; Log.e("onsingString====", signSting); String sign = MD5Utls.stringToMD5(signSting); Retrofit retrofit = new Retrofit.Builder()//Create Rectfit objects .addConverterFactory(GsonConverterFactory.create()) .baseUrl(Url.LIVE_URL_ROOT)//Incoming address .build(); Api aPi = retrofit.create(Api.class);//Instantiating interface objects Call<ResponseBody> call = aPi.getPushUrl2(MyMethod.NAME_PushUrl, MyMethod.VER4_0, MyMethod.userId, timestamp, activityId, sign); call.enqueue(callback); }
Call method to parse data:
The acquisition method of timestamp is defined in BaseActivity, and the current Activity inherits BaseActivity. This can prevent timestamp from expiring to some extent.
NetWorkManager.getPushUrl(activityId, getTimestamp(), new Callback<ResponseBody>() { @Override public void onResponse(Call<ResponseBody> call, Response<ResponseBody> response) { Log.e("onResponsePushUrl", "" + response); } @Override public void onFailure(Call<ResponseBody> call, Throwable throwable) { Log.e("onFailurePushUrl", "" + throwable); } });
END
The project has been uploaded to GitHub, providing a test account, requesting live information to be accessed using Retrofit.
Live-Push-Android