기사가 원문인 경우, 재인쇄 시 원문의 출처를 표기해 주시기 바랍니다.
이 글의 블로그 주소: https://hpzwl.blog.csdn.net/article/details/133022813
Rockchip 개발 칼럼
이전 기사: " RK3568 개발 노트(10): 개발 보드 빌드 루트 펌웨어를 이식하여 개발된 애플리케이션 데모, 전체 화면 디스플레이 시작 "
다음 기사: 계속 지켜봐 주시기 바랍니다...
머리말
대상 개발 작업에는 rtsp 카메라를 재생하는 기능도 있는데, 물론 이를 더 잘 해결하려면 5초에 한 번씩 열도록 재시도하는 등 rtsp 재생이 실패한 후 재시도를 지원해야 합니다. 인터넷에 연결한 후 다시 열 수 있는지 확인한 다음 이 기능을 수행하십시오.
데모
다시 채우다
계획의 빌드루트 덕분에 ffmpeg4.1.3이 포팅되었습니다.
카메라 하드웨어 연결
ffmpeg4.1.3 컴파일
프로그램 이식 과정에서 기본 ffmpge에 swscale.h가 누락되어 처리하기가 매우 어려웠다는 사실이 발견되었습니다 .
패치하는 방법을 생각했는데, ffmpeg4.1.3을 크로스 컴파일하고 다시 패치했습니다.
1단계: 다운로드 및 압축 풀기
http://ffmpeg.org/releases/Unzip
:
2단계: 구성 구성
크로스 컴파일러 소개
export PATH=$PATH:/home/yang/work/src/topeet-qt5.14.2/topeet-qt5.14.2-aarch64/host/bin
다음과 같이 구성을 조정합니다.
./configure --prefix=/home/yang/work/src/topeet-qt5.14.2/topeet-qt5.14.2-aarch64/host/aarch64-buildroot-linux-gnu/sysroot --arch=aarch64 --target-os=linux --enable-cross-compile --cross-prefix=aarch64-buildroot-linux-gnu- --enable-shared
3단계: make 컴파일
make -j4
4단계: make install 설치
make install
5단계: libswsale 이미지 크기 조정 변환 모듈을 확인합니다.
하지만 여전히 컴파일이 작동하지 않습니다.
더 이상 참을 수 없어서 Qt 프로젝트에 대한 전체 종속성 세트를 직접 다시 추출했습니다.
접두사 주소가 수정되었습니다.
./configure --prefix=/home/yang/work/src/ffmpeg-aarch64 --arch=aarch64 --target-os=linux --enable-cross-compile --cross-prefix=aarch64-buildroot-linux-gnu- --enable-shared
다시 살펴보고 ffmpeg 코드만으로 가져옵니다.
코드 모듈에서 가져옵니다.
pri 종속성을 추가합니다.
컴파일하면 이번에는 헤더 파일 오류가 발생하지 않았지만 새로운 오류가 발생했습니다.
컴파일하고 전달합니다.
컴파일 종속성이 해결되었습니다.
6단계: 개발 보드의 ffmpeg4.1.2를 ffmpeg로 덮습니다.
새 라이브러리를 덮어써야 합니다. 그렇지 않으면 다음이 나타납니다.
sftp는 /root 디렉터리를 제한하므로 직접 패키징하고 개발 보드에서 수동으로 복사하여 덮어씁니다.
개발 보드에 복사:
사실 여기서는 헤더파일이 필요없습니다 타겟보드가 컴파일이 안되면 헤더파일이 필요없으니 lib를 직접 압축을 풀고 폴더 안의 모든것을 /usr/lib에 복사하면 됩니다. 아래에 표시됨:
그런 다음 다음을 실행하십시오.
성공적으로 인터페이스를 살펴보십시오.
소프트 디코딩 rtsp 테스트 시작
Ffmpeg는 rtsp 소프트웨어를 가져와 h364 디스플레이(1080p)를 디코딩합니다.
그런 다음 소프트 디코딩 rtsp 재생을 시작합니다.
1초 동안 재생되면 1초씩 증가하여 점점 느려지고, 회색으로 바뀌고 다시 시작됩니다.
CPU를 확인하세요. 1080p를 디코딩하면 CPU가 직접 폭발합니다.
이 접근 방식은 작동하지 않습니다.
Ffmpeg는 rtsp 소프트웨어를 가져와 h364를 디코딩하고 360p(640x360)를 표시합니다.
서브스트림으로 전환:
지연은 약 1s-1.5s입니다.
다음과 같이:
그런 다음 두 개의 디코더를 테스트하고 열었고 지연은 기본적으로 효과가 없었습니다. 그런 다음 응용 프로그램을 실행하여 50ms 동안 데이터를 디코딩하고 상호 작용했습니다. 문제가 없었으므로 먼저 이것을 보여 드리겠습니다.
요약
이번 목표는 기본적으로 달성되었습니다.동시에 rk는 mpp를 사용하여 rtsp를 가져오고 h264 패킷을 rgba로 디코딩할 수 있는 것으로 측정되었습니다. 버퍼 계층을 직접 브러싱하는 것은 지연이 가장 낮고 CPU 소비도 가장 낮을 수 있습니다. qt에도 표시되는데 딜레이가 조금 더 소모되는데, 10~30ms 정도 더 길어야 하고 실제 결과는 테스트가 필요합니다.
이전 기사: " RK3568 개발 노트(10): 개발 보드 빌드 루트 펌웨어를 이식하여 개발된 애플리케이션 데모, 전체 화면 디스플레이 시작 "
다음 기사: 계속 지켜봐 주시기 바랍니다...
기사가 원문인 경우, 재인쇄 시 원문의 출처를 표기해 주시기 바랍니다.
이 글의 블로그 주소: https://hpzwl.blog.csdn.net/article/details/133022813