2014-03-14 2 views
0

카메라에서 rtsp 스트림을 캡처하고 flv로 작성하기 위해 ffmpeg 라이브러리를 코드에 사용합니다. 한 카메라에서만 스트림을 캡처하면 카메라에 비디오 스트림 만 있고 오류가 없으면 첫 번째 패킷에 pts와 dts가 있고 1698557894 및 기타 패킷에는 pts 및 dts가 서서히 증가합니다. 그러나 카메라에 비디오 및 오디오 스트림이 있으면 이상한 일이 발생합니다. 예를 들어, 비디오 패킷 pts 및 dts는 1698557894로 시작하여 서서히 증가하고 오디오는 0으로 시작한 다음 천천히 증가하고 ~ 50 패킷이 값 151004317로 점프하고 천천히 증가합니다. 오디오가 0에서 천천히 증가하고 비디오가 1785662594에서 시작하고 ~ 70 패킷이 234722로 점프하고 천천히 증가하는 또 다른 상황입니다. 이러한 동작은 flv 세그먼트 muxer가 파일을 쓰는 것을 허용하지 않으며, 그냥 EINVAL 값을 반환합니다.카메라의 점과 dts 점프 문제

또한 두 카메라에서 스트림을 캡처하려고하면 첫 번째 카메라에는 비디오 만 있고 다른 카메라에는 비디오 및 오디오가 있으며 첫 번째 카메라 패킷의 pts 및 dts는 정상입니다. 그러나 다른 카메라는 비디오 및 오디오 pts/dts 값이 매우 다릅니다. av_read_frame은 pts/dts 값이 1811924055 인 비디오 패킷을 반환하며 flv muxer에서는 557003451로 다시 조정되고 557003451로 다시 조정되는 오디오는 4456027604이지만이 값은 거의 같아야합니다!

그래서 질문은 다음과 같습니다. 0) 캡처 시작 부분에서 이러한 점프가 발생하는 이유는 무엇입니까? 카메라에 문제가 있거나 그냥 ffmpeg 문제일까요? 1) 오랜 기간 후에 이러한 점프가 발생할 수 있습니까? 어떻게 처리해야합니까? 2) 카메라의 비디오와 오디오의 pts/dts 값이 다른 이유는 무엇입니까?

답변

0

많은 일들이 진행되고 있습니다. 솔직히, 나는 그것을 잘못 구현 된 RTMP 스트림으로 써 버릴 것이다. 그러나 앞으로 나아갈 수있는 몇 가지 요점이 있습니다. 첫 번째 RTMP는 항상 1kHz 클럭을 사용하며 24 또는 32 비트 타임 스탬프를 사용할 수 있습니다. 따라서 타임 스탬프 오버 플로우는 4.6 시간 49.7 일에 일반적입니다. 다음 RTMP는 시간 델타를 지정할 수 있으므로 24 비트 오버 플로우가 가능하며 다음 커플 프레임은 0 (또는 실제로는 0 + 델타)까지 랩핑되기 전에 16777215 이상이됩니다. 그리고 마침내 4456027604는 32 비트 이상입니다. 따라서 ffmpeg를 사용하기 전에 타임 스탬프를 사용하거나 코드에 버그가 있습니다. 행운을 빕니다!