I didn't understood your comment about subscriber choosing vp8..how do they make that choice?
Some Chromium based browsers (Opera, Yandex etc) do not support H264 codec due to license restrictions. If no H264 codec libraries installed on client PC, they can only play VP8. When such a customer complained about it, you 've probably done something like this in your client code:
Code:
playStream = session.createStream({
...stripCodecs: "h264,H264"
}).on(STREAM_STATUS.PENDING, function (playStream) {
...
});
playStream.play();
this should be done depending on client browser only. You're streaming RTMP H264, so try to reduce VP8 usage. We recommend:
1. Detect client browser in JS code
2. Strip H264 codec only for browsers which do not support it (but not for all the browsers)
About MPV, there are probably some customers with legasy iOS devices which does not support WebRTC at all, in that case
WSPlayer only can be used.
For those clients, transcoding will be enabled on server. To decrease server load, you can use lower playback resolution to 480p for example.
480p would be very low res for us to stream..server is hardly doing anything while it's on.. we can increase the memory or cup there if that would help
Now, you have 8 CPU cores (15 with hyperthreading enabled). We recommend you to upgrade server to 16-32 CPU cores.
If there are many VP8 and WSPlayer clients, consider to use
CDN:
- 1 Origin server to publish the stream
- 1 Transcoder stream to transcode it for viewers who cannot play H264
- 1 Edge server to play the stream
In this case, H264 subscribers should play the stream from Edge server by its name, and VP8 subscribers should play the stream by profile, for example streamName-vp8. The profile should be like this:
Code:
-vp8:
audio:
codec: opus
video:
codec: vp8
For MPV subscribers profile should look like this
Code:
-mpv:
audio:
codec: alaw
video:
codec: mpv
width: 640
height: 480
