h264 RTP 패킷의 타임 스탬프에 대해 혼란스러워합니다. 비디오의 벽시계 속도는 SIP SDP에서 정의한 90KHz입니다. 인코더의 프레임 속도가 정확히 30FPS가 아니므로 가변적입니다. 즉석에서 15FPS에서 30FPS까지 다양합니다. 그래서 고정 된 타임 스탬프를 사용할 수 없습니다.h264 RTP 타임 스탬프
다음 중 인코딩 된 패킷의 타임 스탬프를 알려줄 수 있습니까?
0 밀리 초 인코딩 후 RTP 타임 스탬프 = 0 (시작 타임 스탬프 0으로 설정)
50 밀리 초 인코딩 후 RTP 타임 스탬프 =?
40 밀리 초 인코딩 된 RTP 타임 스탬프 =?
33 밀리 초 인코딩 후 RTP 타임 스탬프 =?
인코딩 된 프레임 속도가 가변적 인 공식은 무엇입니까?
미리 감사드립니다.
인코더가 10FPS 또는 30FPS로 비디오를 인코딩하는지 여부는 상관 없습니다. RTP 타임 스탬프는 수신기에 두 프레임 사이의 일시 중지 기간을 알려줍니다. 따라서 각 프레임에 대해 즉석에서 결정합니다. 그렇게하면 1 초 (10fps)로 10 프레임을 전송할 수 있으며, 다른 초에서는 30 프레임 (30fps)을 전송할 수 있습니다. RTP 타임 스탬프를 올바르게 설정하기 만하면됩니다. 그리고 질문에 대한 답을 얻지 못했습니다.
시작 시간 스탬프를 0으로 설정하면 밀리 초 단위로 벽 시계 시간을 마지막 RTP 타임 스탬프에 곱합니다. 원하는 시간 척도를 사용하십시오. , 30 프레임 디코더 디코딩 10fps 영상을 각 패킷에 대해 RTP 타임 스탬프에 333,000을 추가 ...하지만 당신의 예를 살펴 수 있도록하려면, 당신은 당신이 디코더 부하를 만들 것입니다이 (Time in ms * 100000) 같은 RTP 타임 스탬프를 설정한다면
Frame # RTP Time Time between frames [ms]
[ 1] 0 0
[ 2] 50000 50
[ 3] 90000 40
[ 4] 420000 33
프레임 1을 디코딩 한 다음 프레임 2를로드 및 디코딩하지만 프레임 2를 그리기 전에 50ms (프레임 1과 프레임 2의 시간차) 동안 잠자기 상태가됩니다.
그리고 알 수 있듯이, 디코더는 RTP 타임 스탬프를 사용하여 각각을 표시 할 때를 알 수 있습니다. 비디오가 30 또는 10 fps로 인코딩 된 경우 마음에 들지 않습니다.
또한 비디오가 30fps라면 초당 30 개의 RTP 패킷이 있다는 것을 의미하지는 않습니다. 때로는 100 개가 넘을 수 있으므로 올바른 RTP 타임 스탬프 계산을 보장하는 수식을 사용할 수 없습니다.
내가 ...이 당신이 필요로하는 무엇이라고 생각 해달라고 -1 나를 I didnt한다 ... =이)
이에 대한 간단한 공식이없는 경우, 내가 도움이되기를 바랍니다.
인코딩 전에 프레임 샘플링에 사용되는 순간을 PTS (프레젠테이션 타임 스탬프)라고합니다. 인코더의 범위를 벗어 났으므로 프레임을 캡처 할 때 데이터 흐름에서이를 기억해야합니다.
거기서경우 2 개의 가능성이 있습니다
후자의 경우 RFC6184에는 인코딩 된 NAL 단위를 스트리밍하는 여러 가지 방법이 있다고 나와 있습니다.
대부분의 스트리밍 소프트웨어는 "비 인터리빙"모드를 사용합니다.이 모드에서는 타임 스탬프가 단조롭게 증가하지 않도록 RTP 타임 스탬프를 PTS + 오프셋으로 설정하고 디코딩 순서로 보내야합니다. 이것은 또한 클라이언트가 수신 된 순서대로 디코드해야하고 PTS 순서로 프레임 순서를 바꾸지 않아야 함을 의미합니다. 당신이 일을 단지 순서를이에 대한 디코딩 타임 스탬프을 필요로하지 않기 때문에
나는 이유가 여기에 용어를 DTS를 사용하지 않는.
RFC6184에 설명 된 마지막 모드는 NAL 단위를 재정렬 할 수있는 소위 인터리브 된 순서입니다. 이 경우 장치를 재정렬하기 위해 일부 응용 프로그램 논리를 구현해야합니다 (자세한 내용은 RFC6184 참조).
나에게는 분명하지 않습니다. 내가 [bitstream] (http://stackoverflow.com/questions/10562549/send-android-h264-capture-over-a-rtp-stream) 어디에 내가 nalu를 분석하고 그들에게 trhough rtp를 보내려고 노력했습니다. 것은 타임 스탬프를 직접 계산해야한다는 것입니다. 현재 나는 그것을 잘못하고 있다고 확신한다. (timestamp-lasttimestamp) * 100000. 비트 스트림에서 새로운 nalu를 읽을 때마다 새 타임 스탬프를 설정했지만 그 형식은 패킷과 패킷 사이의 타임 스탬프를 변경합니다. 패킷 A는 패킷 B보다 더 큰 타임 스탬프를 가질 수 있습니다! – FlaPer87
RTP 타임 스탬프는 프레임 간의 시간차 이외에 절대 시간을 알려줍니다. 그렇지 않으면 오디오와 비디오를 동기화하는 데 사용할 수 없습니다. –
@RioWing 아니요, 32 비트 정수 필드에서 절대 64 비트 시간 값을 안정적으로 설정할 수 없습니다. 포인트는 타임 스탬프가 선형 적으로 증가해야한다는 것과, 타임 스탬프를 설정할 때 CLOCK RATE 값을 염두에 두어야한다는 것입니다. 즉, 1 AV second'last_frame_timestamp - first_frame_timestamp = CLOCK_RATE'. 올바른 타임 스탬프 (틱)와 같은 원하는 다른 데이터를 저장하는 RTP 확장 헤더가 있습니다. – Cipi