FFMedia란 무엇인가요?
Rockchip RK3588 시리즈 SoC(시스템 온 칩)는 뛰어난 비디오 인코딩 및 디코딩 기능을 제공하며, 특히 다중 채널 비디오 동시 처리 성능이 뛰어납니다. 그러나 비디오 처리 애플리케이션을 개발할 때 gstreamer나 ffmpeg와 같은 일반 프레임워크가 칩 성능을 충분히 발휘하지 못하거나, 공식 API가 하위 계층에 너무 가깝거나, 높은 학습 비용, 긴 개발 주기, 그리고 과중한 개발 부담 등의 문제에 직면하는 경우가 많습니다.
각 단원의 주요 구성 요소는 다음과 같습니다.
- 입력 단위: rtsp, rtmp, whep, camera, file 등의 입력 단위를 포함합니다.
- 처리 장치: 하드웨어 디코딩, 인코딩, 이미지 처리 및 추론 장치와 하드웨어 가속을 지원하는 기타 처리 장치가 포함됩니다.
- 출력 단위: rtsp, rtmp, whip, drm display, gb28181, file 및 기타 출력 단위가 포함됩니다.
기능 및 특징
핵심 아키텍처
- 모듈형 아키텍처: 전체 프레임워크는 생산자/소비자 모델을 채택하고, 각 단위는 ModuleMedia 클래스로 추상화됩니다.
- 효율적인 메모리 관리 기술: 장치와 하드웨어 간의 데이터 상호작용은 제로 복사를 사용하여 구현됩니다.
미디어 처리 기능
- 포맷 지원: mp4/mkv/flv/ts와 같은 주요 컨테이너 포맷과 rtsp/rtmp/gb28181/webrtc와 같은 주요 프로토콜의 구문 분석 및 캡슐화를 지원합니다.
- 변환 및 처리: 비디오 변환, 자르기, 스플라이싱, 워터마킹 및 기타 처리를 지원합니다.
- 스트리밍 미디어 처리: 카메라 및 네트워크 스트림과 같은 소스에서 미디어 스트림을 가져와 실시간 처리, 전달 및 저장을 지원합니다.
성능 최적화
- 낮은 부하 및 낮은 대기 시간: GStreamer 및 FFmpeg에 비해 CPU 사용량이 적고 데이터 실시간 성능이 더 높아 데이터 스트림 처리 및 전송을 심층적으로 최적화합니다.
- 효율적인 Python 모듈: pybind11을 통해 C++와 Python 간의 원활한 상호 운용성이 달성됩니다.
- 통합 인터페이스: 복잡한 기본 작업을 보호하고 최적화하여 사용자에게 효율적이고 통합된 인터페이스를 제공합니다.
플랫폼 호환성
- 칩 수준 적응: Firefly 플랫폼에서 모든 Rockchip 머신 모델을 지원합니다.
- 시스템 지원: Buildroot/Ubuntu/Debian 등 다양한 버전의 시스템을 지원합니다.
소스 코드 다운로드
소스 코드 가져오기:
-
git clone https://github.com/Firefly-rk-linux-utils/ffmedia_release.git
개발 인터페이스
모든 인터페이스는 C++ 및 Python 호출을 지원합니다.
C++ 언어 패러다임:
-
auto rtsp_c = make_shared <modulertspclient>("rtsp://xxx");
-
auto ret = rtsp_c->init()
Python 언어 패러다임:
-
auto rtsp_c = make_shared
("rtsp://xxx"); -
auto ret = rtsp_c->init()
일반적인 시나리오 및 성능 테스트
테스트 환경: ITX-3588J ITX 마더보드
저지연 라이브 스트리밍
다음 모듈을 사용하여 H265 1080p@30fps RTSP 라이브 스트림 재생을 테스트해 보세요.
- RTSP 클라이언트: 자체 구현된 가벼운 RTSP 클라이언트 모듈이 사용됩니다. 스트림의 한 프레임을 가져오는 데 약 0.03밀리초가 걸립니다.
- MPP 디코딩: MPP 구현을 기반으로 한 디코딩 모듈. 한 프레임을 디코딩하는 데 약 1.2밀리초가 걸립니다(다중 채널 모드에서는 0.7밀리초까지 낮아질 수 있음).
- DRM 디스플레이: DRM 프레임워크 기반의 디스플레이 모듈입니다. 한 프레임을 보내고 표시하는 데 약 0.9밀리초가 걸립니다.
H265(p 프레임 시리즈는 순차적) 및 1080P 라이브 방송의 지연 시간을 계산할 수 있습니다. 네트워크에서 데이터 스트림을 YUV 원시 스트림으로 디코딩하는 데 걸리는 지연 시간은 약 1.3밀리초이며, 화면 표시는 화면 주사율의 영향을 받습니다. 예를 들어, 60fps의 화면 주사 간격은 16.667밀리초이고, 표시 지연 시간은 0.9~16.667밀리초로 계산할 수 있습니다. 요약하자면, 1080P 라이브 방송의 최소 지연 시간은 약 2.4밀리초입니다.
성과 지표는 다음 표에 나와 있습니다.
CPU 사용량 | 메모리 사용량 | 프레임 처리 시간 |
1.0% | 7200만 | 2.4ms |
간단한 테스트 명령은 다음과 같습니다.
-
./demo rtsp://xxx -d 0
32채널 H265 1080p@30fps RTSP 실시간 스트림의 테스트 재생 성능 지표는 다음 표에 나와 있습니다.
CPU 사용량 | 메모리 사용량 |
23.5% | 2.8GB |
간단한 테스트 명령은 다음과 같습니다.
-
./demo rtsp://xxx -d 0 -c 32
실시간 비디오 스트리밍 트랜스코딩 및 방송
관련 모듈을 사용하여 H265 1080p@30fps RTSP 라이브 스트림을 H264 RTSP 스트림으로 변환하는 것을 테스트합니다.
- RTSP 클라이언트: 가벼운 RTSP 클라이언트 모듈입니다. 한 프레임을 가져오는 데 약 0.03밀리초가 걸립니다.
- MPP 디코딩: MPP 구현을 기반으로 한 디코딩 모듈. 한 프레임을 디코딩하는 데 약 1.2밀리초가 걸립니다(다중 채널 모드에서는 0.7밀리초까지 낮아질 수 있음)
- MPP 인코딩: MPP 구현 기반 인코딩 모듈; 한 프레임을 인코딩하는 데 약 4.8밀리초가 걸립니다(다중 채널 모드에서는 2.5밀리초까지 낮아질 수 있음)
- RTSP 서버: 가벼운 RTSP 서버 모듈입니다. 한 프레임을 푸시하는 데 약 0.1밀리초가 걸립니다.
스트리밍, 트랜스코딩에서 스트리밍으로 비디오 프레임이 변환되는 데 걸리는 이론적인 시간은 약 6.3밀리초라고 예비적으로 추정할 수 있습니다.
성과 지표는 다음 표에 나와 있습니다.
CPU 사용량 | 메모리 사용량 | 프레임 처리 시간 |
1.0% | 112M | 6.3MS |
간단한 테스트 명령은 다음과 같습니다.
-
./demo rtsp://xxx -e h264 -p 8554
-
# You can use demo or other software to pull the transcoded rtsp stream: rtsp://ip:8554/live/0