kiến thức Demo streaming server bằng rtmp với opensource + android

an21345

Senior Member
Chào các fen, hôm nay mình rảnh, nên muốn chia sẻ với các fen cách dựng 1 server livestream bằng rtmp, hls, http-flv, webrtc protocol và android app. Opensource có sẵn trên github.

Do năm 2020 mình có làm product ở vitmap về cái livestream này nhưng vẫn còn nhiều vấn đề chưa giải quyết được. Như việc scaleup, optimize, loadbalancing.
Hi vọng sau bài viết này các fen có thể tự dựng 1 cái server livestreaming nho nhỏ hoặc to đủ sức để cạnh tranh với VNG, FPT, navitel, vitmap, ...
Các fen chờ mình lên github chọn hàng nhé, 2 năm rồi mình không có nhớ link nằm đâu hết.:byebye:
Đã đủ hàng, link ở dưới rồi nhé các fen.

Mục tiêu và các thành phần:
  1. Server opensource tương tự wowza, hỗ trợ website preview livestream, các bạn có thể nhúng cái view này ở mọi chỗ. Vì server hỗ trợ rtmp, hls, http-flv, webrtc, ... nên js có khá nhiều thư viện hỗ trợ. (rtmp thì flv.js nó ngừng hỗ trợ rồi nên hơi khó để nhúng vô private website nhưng yên tâm muốn làm là có cách hết) - ossrs/srs
    ossrs official website
  2. App android opensource code sẵn việc thao tác với camera, và upload rtmp lên server rtmp ở trên. Mình chỉ cần cấu hình đúng link là được. - begeekmyfriend/yasea
Các kiến thức căn bản cần có:
  1. Docker (căn bản luôn)
  2. K8S (điểm cộng thôi nhé nhưng docker 1 điểm thì k8s 11 điểm lận, cái này nâng cao nhé, scaleup, balancing, routing, ...)
  3. ffmpeg (cái tool transform các loại video formats, rất là mạnh nhé cái này rất quan trọng)
  4. rtmp protocol (chắc chắn là phải hiểu rồi nhưng không cần quan tâm lắm đâu vì biết cách xài ffmpeg là tha hồ chơi rtmp)
  5. Android (biết cài tool build code android là ok, có sửa url để upload rtmp cho đúng thôi không khó lắm)
  6. 1 chút kiến thức về BE và FE để hiểu flow và biết rõ chỗ bị issue để giải quyết vấn đề 1 cách nhanh chóng.
Kết quả cần đạt được:
  1. Triển khai được 1 hệ thống livestream low lantency.
  2. Xem được trên website với thiết bị Android đang livestream.
  3. Có thể nâng cấp hay update 1 app Android một cách dễ dàng.
  4. Có thể tự viết 1 website mới để phát rtmp, webrtc video đang livestream.
  5. Có kiến thức về các protocol livestream hiện đại.
  6. Biết cách loadbalancing, scaleup, optimize lantency.
  7. Tự tin research những công nghệ mới bằng các kiến thức trên.
Tổng quan về các livestreaming protocol:
  1. HLS: Apple xài chuẩn này, Android cũng đùng được luôn nhé. Cốt lõi của giao thức này là cắt video ra làm nhiều đoạn nhỏ (1 video được cắt ra làm nhiều chunk) và website (hay gọi là client) sẽ phát chunk 1 rồi tới chunk 2, ... (ta có thể giới hạn maximum chunk ở server, kể cả việc clear hết các chunk sau 1 khoảng thời gian Android dừng upload video qua rtmp, nói chung là server cấu hình file config nhiều tham số lắm, bạn tha hồ mà vọc vạch)
    1. Ưu điểm:
      1. Triển khai đơn giản, nhúng vô mọi chỗ được.
      2. Có thể tua các đoạn chunk như xem video vậy đó.
    2. Nhược điểm:
      1. Vì các chunk có độ dài bằng nhau (mặc định là 10s) nên độ trễ của quá trình livestream rơi vào khoảng (-10,10) giây.
    3. Tối ưu:
      1. Apple có tối ưu giao thức hls này bằng hls2 (low lantency), bằng cách giảm độ dài 1 chunk, ở mức chấp nhận được. Low lantency rơi vào khoảng 1-2s, có thể xem là chấp nhận được.
  2. HTTP-FLV: Giao thức khá là cũ, đa số video upload lên được convert sang dạng flv. Chính vì video format theo flv nên 1 số website nhúng vào sẽ khó, nhất là các thiết bị Apple.
    1. Ưu điểm:
      1. Delay lantency thấp. (300-1000ms-2s nói chung là khá nhỏ và phụ thuộc nhiều vào brandwith network nhà bạn)
      2. Nhúng vô Android, website thì có flv.js lo hết.
      3. Giao thức cơ bản dễ tìm được thư viện hỗ trợ.
    2. Nhược điểm:
      1. Vì video format theo dạng flv nên khó nhúng vô hàng Apple, flv.js thì không chơi với Apple rồi.
  3. WebRTC: Tương tự như RTMP, nhưng video không format theo kiểu rtmp, cũng chưa rõ video format kiểu gì nữa.(Có gì update sau nhé các fen)
    1. Ưu điểm:
      1. Ưu điểm giống RTMP.
      2. Delay lantency thấp.
      3. Nhúng vào website, Android cũng dễ, Apple thì mình chưa thử. (Có vẻ là không có thư viện hỗ trợ để phát trên hàng Apple)
    2. Nhược điểm:
      1. Được đánh giá là không an toàn về bảo mật, đo phải public 1 phần ip, port hoặc domain.
Các bước thực hiện:
  1. Cách run docker image ossrs/srs:4
    Port 1935 là port upload video bằng rtmp từ device, admin page là 1985 - lên trang này để xem ip nào đang push video, 8080 là port website để mình lên xem livestream và test các protocol rtmp, hls, webrtc,...
    (Trong này còn có file srs.conf, có vài tham số để các bạn cấu hình, tham khảo thêm ở link này nhé - config file)
    1. Code:
      docker run --rm -it -p 1935:1935 -p 1985:1985 -p 8080:8080 \
          ossrs/srs:4 ./objs/srs -c conf/docker.conf
      Lệnh này để run srs container và public đám port.
    2. Code:
      docker run --rm -it ossrs/srs:encoder ffmpeg -stream_loop -1 -re -i doc/source.flv \
        -c copy -f flv rtmp://host.docker.internal/live/livestream
      Lệnh này sẽ push video có sẵn trong container, các fen đỡ mất công đi kiếm và cài cái ffmpeg chi cho mất thời gian.
    3. Code:
      http://localhost:8080/players/srs_player.html?autostart=true&stream=livestream.m3u8&port=8080&schema=http
      Sau khi chạy xong 2 lệnh trên, ta vào link trên để xem livestream bằng hls.
      2MptlKX.png
    4. Code:
      http://localhost:8080/console/en_index.html#/connect?port=1985&schema=http&host=localhost
      Các fen vào link này để connect console view của srs server.
      Trong này có thể xem được danh sách các device đang push video và preview livestream. Nhớ bấm connect để kích hoạt nhé.
      OQHWyO4.png
    5. Sau khi click connect thì vô link này để xem danh sách các device đang push video lên srs server. Bấm vô preview để mở tab mới xem livestream nhé.
      Code:
      http://localhost:8080/console/en_index.html#/streams?port=1985&schema=http&host=localhost
      a0oQwCK.png
    6. Ấn vô preview thì qua tab xem livestream, auto đúng link luôn nhé.
      GhvTZlw.png
    7. Cấu hình OBS để stream lên srs server.
      UjnNZ5r.png
    8. Đây là cách SRS storage video m3u8 và ts. Chui vô trong container đúng folder nha.
      gN4CwAC.png
    9. Vậy là việc test srs server đã xong, khá là dễ để test.
  2. Android app rtmp: trong này có thư viện rtmp java+cpp+jni đủ cả, nhưng mình cũng chẳng cần phải đọc kĩ làm gì hết, người ta viết ok lah rồi, ai thích vọc vạch thì vô đọc thử xem người ta viết hưu viết vượn gì nhé.
    (mình chuẩn bị cài android studio vô win10, rồi còn phải check lại gradle, lib cho phù hợp với version sdk android 21, nên sẽ tốn cỡ 30p gì đó, cái cấu hình lib này mình làm rất nhiều lần vào năm 2017-2020 rồi nên không lo lắm)
Đang viết tiếp nhé, cần phải crop 1 số ảnh để chứng minh là mình đã test thành công.
Mình sẽ cài docker lên con máy windows 10.
Sẵn tiện mình dùng thử cái docker+wsl2 cho các bạn biết luôn. (vì giờ mà cài ảo hóa vmware rồi cài ubuntu, docker thì tốn thời gian quá, hiệu suất nó lại chậm lag lòi nữa. Tuần trước bên f33 có người bảo là wsl2 + docker ngon hơn hyper-v nên giờ thử luôn coi M$ có phải là lựa chọn tốt không nhé)

Sau khi thử docker + wsl2 thấy tụi này chạy cũng ok, cài đặt dễ, không có gì rắc rối hơn so với hyper-v. Tóm lại là xài ngon nhé các fen, môi trường wsl2 linux thì tiết kiệm ram và cpu hơn là cái chắc rồi.

Ai chê hàng tầu thì nên cân nhắc lại vì cái srs này nó hơn 21.7k star trên github lận. Đúng nhận sai cãi nhé, không phải cứ hàng tầu là auto cùi đâu, nước tỉ dân nó nhiều hàng xịn mà không public lắm. Có sẵn thì cứ tận hưởng thôi, không cần phải tốn công tự viết rồi mất công bảo trì.
Cứ trên lưng người khổng lồ và tiết kiệm thời gian của bản thân là tốt nhất.

p/s:
  1. Vmware là đồ cổ của 2015 rồi nhé các fen. Còn ai muốn tìm hiểu thêm tại sao vmware lại bị lạc hậu thì link đây nhé. - docker vs vmware
    Sơ qua tí thì các máy host: 100% CPU + 4GB RAM, triển khai 2 cái ảo hóa win10 chiếm tổng là 2GB RAM + 50% CPU, máy host chỉ còn lại 2GB RAM và 50% cpu cho các tác vụ khác.
    Việc 2 win10 có chung hệ điều hành bị duplicate lên => lãng phí.
    Để tránh lãng phí này, người ta để ra 1 cái chung gọi là môi trường docker cài sẵn windows lên đó, các container là các application sẽ dùng tài nguyên như libs, cpu, ram từ docker enviroment và máy host sẽ không còn bị chiếm 50% CPU và 2GB RAM nữa. Thay vào đó docker sẽ sử dụng cỡ chừng 1GB RAM và 25% CPU. Chúng ta có thể sử dụng 3 GB RAM + 75% CPU cho việc khác.
    Quả là tiết kiệm tài nguyên khi sử dụng docker phải không?
    containers-vs-virtual-machines.jpg
  2. Giờ người ta chơi lightweight container - containerd + k8s, private docker hub - versioning, grafana - monitoring - alert, prometheus - logging, jenkins - auto build + deploy script, ...
  3. Mấy cái trên là căng bản để CI/CD đó.
Cám ơn các fen đã giúp đỡ mình hoàn thiện bài viết:
@FullStackFlutterGolang
 
Last edited:
hóng ạ :V, mà bác cho e hỏi bác có biết nhúng ffmpeg vô android k ạ, e có thử tìm hiểu mà làm k được
 
hóng ạ :V, mà bác cho e hỏi bác có biết nhúng ffmpeg vô android k ạ, e có thử tìm hiểu mà làm k được
Có opensource và lib trên github đó fen.
Người ta viết sẵn code Android lấy video từ camera đẩy qua ffmpeg của lib luôn đó.
Chịu khó search phát là ra à.
 
Chào các fen, hôm nay mình rảnh, nên muốn chia sẻ với các fen cách dựng 1 server livestream bằng hls, rtmp, webrtc protocol và android app. Opensource có sẵn trên github.

Do năm 2020 mình có làm product ở vitmap về cái livestream này nhưng vẫn còn nhiều vấn đề chưa giải quyết được. Như việc scaleup, optimize, loadbalancing.
Hi vọng sau bài viết này các fen có thể tự dựng 1 cái server livestreaming nho nhỏ hoặc to đủ sức để cạnh tranh với VNG, FPT, navitel, vitmap, ...
Các fen chờ mình lên github chọn hàng nhé, 2 năm rồi mình không có nhớ link nằm đâu hết.:byebye:
Đã đủ hàng, link ở dưới rồi nhé các fen.

Mục tiêu và các thành phần:
  1. Server opensource tương tự wowza, hỗ trợ website preview livestream, các bạn có thể nhúng cái view này ở mọi chỗ. Vì server hỗ trợ hls, rtmp, webrtc, ... nên js có khá nhiều thư viện hỗ trợ. (rtmp thì flv.js nó ngừng hỗ trợ rồi nên hơi khó để nhúng vô private website nhưng yên tâm muốn làm là có cách hết) - ossrs/srs
  2. App android opensource code sẵn việc thao tác với camera, và upload rtmp lên server rtmp ở trên. Mình chỉ cần cấu hình đúng link là được. - begeekmyfriend/yasea
Các kiến thức căn bản cần có:
  1. Docker (căn bản luôn)
  2. K8S (điểm cộng thôi nhé nhưng docker 1 điểm thì k8s 11 điểm lận, cái này nâng cao nhé, scaleup, balancing, routing, ...)
  3. ffmpeg (cái tool transform các loại video formats, rất là mạnh nhé cái này rất quan trọng)
  4. rtmp protocol (chắc chắn là phải hiểu rồi nhưng không cần quan tâm lắm đâu vì biết cách xài ffmpeg là tha hồ chơi rtmp)
  5. Android (biết cài tool build code android là ok, có sửa url để upload rtmp cho đúng thôi không khó lắm)
  6. 1 chút kiến thức về BE và FE để hiểu flow và biết rõ chỗ bị issue để giải quyết vấn đề 1 cách nhanh chóng.
Kết quả cần đạt được:
  1. Triển khai được 1 hệ thống livestream low lantency.
  2. Xem được trên website với thiết bị Android đang livestream.
  3. Có thể nâng cấp hay update 1 app Android một cách dễ dàng.
  4. Có thể tự viết 1 website mới để phát rtmp, webrtc video đang livestream.
  5. Có kiến thức về các protocol livestream hiện đại.
  6. Biết cách loadbalancing, scaleup, optimize lantency.
  7. Tự tin research những công nghệ mới bằng các kiến thức trên.
Tổng quan về các livestreaming protocol:
  1. HLS: Apple xài chuẩn này, Android cũng đùng được luôn nhé. Cốt lõi của giao thức này là cắt video ra làm nhiều đoạn nhỏ (1 video được cắt ra làm nhiều chunk) và website (hay gọi là client) sẽ phát chunk 1 rồi tới chunk 2, ... (ta có thể giới hạn maximum chunk ở server, kể cả việc clear hết các chunk sau 1 khoảng thời gian Android dừng upload video qua rtmp, nói chung là server cấu hình file config nhiều tham số lắm, bạn tha hồ mà vọc vạch)
    1. Ưu điểm:
      1. Triển khai đơn giản, nhúng vô mọi chỗ được.
      2. Có thể tua các đoạn chunk như xem video vậy đó.
    2. Nhược điểm:
      1. Vì các chunk có độ dài bằng nhau (mặc định là 10s) nên độ trễ của quá trình livestream rơi vào khoảng (-10,10) giây.
    3. Tối ưu:
      1. Apple có tối ưu giao thức hls này bằng hls2 (low lantency), bằng cách giảm độ dài 1 chunk, ở mức chấp nhận được. Low lantency rơi vào khoảng 1-2s, có thể xem là chấp nhận được.
  2. RTMP: Giao thức khá là cũ, đa số video upload lên được convert sang dạng flv. Chính vì video format theo flv nên 1 số website nhúng vào sẽ khó, nhất là các thiết bị Apple.
    1. Ưu điểm:
      1. Delay lantency thấp. (300-1000ms-2s nói chung là khá nhỏ và phụ thuộc nhiều vào brandwith network nhà bạn)
      2. Nhúng vô Android, website thì có flv.js lo hết.
      3. Giao thức cơ bản dễ tìm được thư viện hỗ trợ.
    2. Nhược điểm:
      1. Vì video format theo dạng flv nên khó nhúng vô hàng Apple, flv.js thì không chơi với Apple rồi.
  3. WebRTC: Tương tự như RTMP, nhưng video không format theo kiểu rtmp, cũng chưa rõ video format kiểu gì nữa.(Có gì update sau nhé các fen)
    1. Ưu điểm:
      1. Ưu điểm giống RTMP.
      2. Delay lantency thấp.
      3. Nhúng vào website, Android cũng dễ, Apple thì mình chưa thử. (Có vẻ là không có thư viện hỗ trợ để phát trên hàng Apple)
    2. Nhược điểm:
      1. Được đánh giá là không an toàn về bảo mật, đo phải public 1 phần ip, port hoặc domain.
Các bước thực hiện:
Viết sau nhé, chắc chắn là phải dùng docker rồi vì ai mà rảnh cài cái đống này lên máy host chứ.
Hi vọng không ngâm như seri hoả chí của feng
 
Ngoài lề xíu có cách nào bypass cors bằng java web ko nhỉ?
Ko có time tìm hiểu.
không nhé fen.
server nó allow cors domain nào trong list thì domain đó mới được nhúng hoặc gọi vô thôi.
cái này là tiêu chuẩn chung của browser và method restful api rồi.
 
K8S khó xài phết ấy bác, nghịch cho vui thôi chứ mang vào production thì ti tỉ vấn đề :D
k8s gõ lệnh sướng mà fen, map physical disk, config key, ...
Phải gọi là sướng trợn ngược trợn xuôi, mình cài k8s standalone lên production server thấy chạy khỏe lắm.
Docker sao mà deploy production được, chỉ có k8s mới chịu tải cho production được thôi.
 
Con cũ của bác lúc cao điểm chạy bao nhiêu user live stream cùng 1 lúc ?
Cấu hình server lúc đó ra sao vậy ?
Hồi ở vitmap 2020 cỡ hơn 1k user cùng livestream 1 lúc.
Do 1 xe gắn 1 device có 4 camera nên x4 lên nhé fen, nói chung là vẫn mượt lắm dù mới 1 instance thôi.
Chủ yếu bán cho doanh nghiệp vận tải vụ nghị định 10 đó.
Hồi đó nghe đâu là 50k xe đó.
Mình cũng không nhớ rõ lắm.
Con số device realtime thì khoảng là 1k-2k vì tụi này nó gửi gps liên tục.
Còn bên khách hàng thì họ mở cái website livestream liên tục luôn, tối ngày khách báo sim trên device hết băng thông do họ livestream cả 4 cam.
 
k8s gõ lệnh sướng mà fen, map physical disk, config key, ...
Phải gọi là sướng trợn ngược trợn xuôi, mình cài k8s standalone lên production server thấy chạy khỏe lắm.
Docker sao mà deploy production được, chỉ có k8s mới chịu tải cho production được thôi.
Workload streaming như này để scale thì đúng cần k8s thật, nma khi xảy ra vde debug thì cũng sướng trợn mắt luôn bác :D cá nhân em nhận thấy trừ khi cần scale rất lớn mới động đến k8s, còn lại xài ui quản lý như portainer kết hợp với docker là đủ mần rồi :D
 
Workload streaming như này để scale thì đúng cần k8s thật, nma khi xảy ra vde debug thì cũng sướng trợn mắt luôn bác :D cá nhân em nhận thấy trừ khi cần scale rất lớn mới động đến k8s, còn lại xài ui quản lý như portainer kết hợp với docker là đủ mần rồi :D
Cứ thử từng cái nhỏ đi fen, đừng quá lo về vấn đề.
Monitoring, trace log đầy đủ là được hết.
 
Hồi ở vitmap 2020 cỡ hơn 1k user cùng livestream 1 lúc.
Do 1 xe gắn 1 device có 4 camera nên x4 lên nhé fen, nói chung là vẫn mượt lắm dù mới 1 instance thôi.
Chủ yếu bán cho doanh nghiệp vận tải vụ nghị định 10 đó.
Hồi đó nghe đâu là 50k xe đó.
Mình cũng không nhớ rõ lắm.
Con số device realtime thì khoảng là 1k-2k vì tụi này nó gửi gps liên tục.
Còn bên khách hàng thì họ mở cái website livestream liên tục luôn, tối ngày khách báo sim trên device hết băng thông do họ livestream cả 4 cam.
bác chia sẻ thêm về case 1k-2k CCU của bác với, bao nhiêu streamer, streamee? băng thông server như thế nào? sử dụng protocol nào cho case này?
 
bác chia sẻ thêm về case 1k-2k CCU của bác với, bao nhiêu streamer, streamee? băng thông server như thế nào? sử dụng protocol nào cho case này?
1k device có 4 cam cùng live 1 lúc.
NAS brandwidth 10 GHz, CPU 12 core - 6 thread 2.2GHz, RAM 8GB, SSD 100GB, k8s 3 node ubuntu.
Nhưng srs server chỉ chạy 1 instance đã đủ cho 1k device push 4 cam và pull 4 cam phía website (doanh nghiệp vận tải họ mở cả trăm tabs để xem hết tất cả device, xem liên tục 24h luôn nha fen.
protocol device: rtmp.
pull video protocol: http-flv, hls.

Bài viết trên chỉ là để các fen demo và hiểu cách mà các hệ thống livestream hiện đại họ làm như thế nào.
Các fen nếu thực hành được thì có thể dựng 1 cái private livestream server ở nhà trên máy localhost.
Không cần phải lo đến việc scale up đâu vì 1 instance này đã đủ dư cho 10 device 2 camera trước sau livestream cùng 1 lúc rồi.

Nếu fen nào muốn đo performance thì lên trang official mà đọc nhé.
ossrs official website
 
Back
Top