Deep Understanding of Seek
입문
ExoPlayer에서 다음 검색을 수행할 수 있습니다.
player.seekTo(positionMs)
이번에 우리는 이것이 내부에서 무엇을 하는지 상세하게 설명할 것이다.
구체적으로 말하면
player.seekTo(positionMs)
참고) ExoPlayer2.10.8을 검증합니다.
참고) ExoPlayer의 말이기 때문에 다른 Player의 논리와 결과 등이 다를 수 있습니다.
검색의 정확성
검색의 정확성을 알기 위해서는 먼저 pts(presentation time stamp)를 알아야 한다.
애니메이션은 한 장의 순간을 나타내는 프레임이라고 불리는 집합체로 구성되지만 영상은 이 프레임을 통해 파라파라 만화처럼 연속적으로 그려진다.그리고 이 하나하나의 프레임은 pts의 프레임을 표시해야 하는 시간을 나타내는 시간 스탬프와 관련이 있습니다. 그 시간이 되면 decode의 프레임을 그려야 합니다.
즉, 영상이 가지고 있는 최소 시간 단위가 바로 이 pts라는 것이다.
(pts 이외에dts(decode time stamp) 등이 있습니다.)
이 영상이 가지고 있는 최소 단위 시간 pts를 바탕으로 검색frame accurate seeking
을 하고 프레임 단위로 검색 위치에 가장 적합한 프레임을 찾아 프레임부터 그린다.
다른 한편, key-frame accurate seeking
라고 불리는 것도 있다.이것은 Key-Fame 단위로 검색 위치를 검색합니다. 검색된 프레임은 프레임 accurate seeking보다 빨리 표시되지만 프레임 accurate seeking보다 정확한 위치는 아닙니다.
즉, 느리지만 정확한frame accurate seeking
, 이르지만 애매한key-frame accurate seeking
이다.
ExoPlayer에서 사용할 수 있는 것은 기본값입니다frame accurate seeking
.
찾는 데 걸리는 시간
ExoPlayer는 frame accurate seeking
를 사용합니다. 프레임을 어떻게 찾았습니까?
ExoPlayer는 SyncPoints의 개념에 따라 찾아야 할 프레임을 찾았습니다.
SyncPoints는 프레임 등을 표시합니다. 그들은 검색 가능한 특정 구간을 구분하고 이 특정 프레임으로 구분된 구간에 따라 프레임을 검색할 수 있습니다.
그렇다면 검색 가능한 특정 구간을 구분할 수 있는 프레임은 어떤 프레임을 가리키나요?
이것은 흐름식 전송 프로토콜과 윤곽 형식에 달려 있다.
예를 들어 progressive에 재생되는 mp4의 경우 stbl
상자에서 키프레임의 위치를 확인할 수 있기 때문에 SyncPoints는 키프레임입니다.또한 fmp4에서 재생된 MPEG-DASH의 경우 SyncPoints는 fmp4로 구분된 구간이고, MPEG2-TS에서 재생된 HLS의 경우 SyncPoints는 각 TS 파일입니다.
검색할 프레임을 찾으면 ExoPlayer는 이 구간에서 데이터를 디코더에 넣고 디코딩을 시작합니다.
여기서 주의해야 할 것은 seek의 프레임이 아니라 구간의 첫 번째 프레임에서 디코더에 쌓이는 것이다.따라서 ExoPlayer는 isDecodeOnly의 로고를 구간에서 시작하는 프레임부터seek 프레임 이전의 Buffer에 추가합니다.이 로고를 추가하면 디코더는 구간에서 시작하는 프레임부터seek 프레임 이전의 프레임을 디코딩하지만 디코딩 후의 프레임은 그리지 않고 skip입니다.
그런 다음 프레임 뒤에 있는 프레임을 디코딩하면 프레임이 Surface에 그려집니다.
(seek를 원하는 프레임 이전의 Key-Fame에서 왜 Decoder를 넣지 않았는지 모르겠다.)
SeekParameters
검색 과정은 검색할 프레임과 검색 프레임의 decode 과정을 통해 일정한 시간을 소비합니다.
SeekParameters는 검색 프로세스의 시간을 단축할 수 있습니다.
SeekParameters: EXACT, CLOSEST_SYNC, PREVIOUS_SUNC, NEXT_SYNC에는 네 가지가 있습니다.
EXACT는 지금까지 설명한 것frame accurate seeking
이며, 그 외의 것은 찾아야 할 대상의 프레임을 SyncPoints로 분리하는 프레임으로 설정합니다.이렇게 하면 불필요한 인코딩 과정을 절약하고 찾을 수 있어 프레임 1을 표시하는 시간을 줄일 수 있다.
다음은 구분된 점의 프레임을sync-frame로 읽습니다. 아까 SyncPoints의 정의를 보면 이sync-frame은 어떤 경우 Key-Fame이지만 재생 종류에 따라 때로는 Key-Fame 단위도 아니기 때문에 정확하게 말하면 아니기 때문입니다key-frame accurate seeking
.
SeekParameters
개요
EXACT
Default 검색 방법가장 가까운 프레임을 찾아라.
CLOSEST_SYNC
최근sync-frame을 찾습니다.
PREVIOUS_SYNC
마지막 sync-frame을 찾습니다.
NEXT_SYNC
최근sync-frame을 찾습니다.
HLS 검색이 느립니까?
ExoPlayer로 HLS의 흐름을 검색하면 다른 재생 종류에 비해 검색이 압도적으로 느립니다.
이는 일반적으로 TS 파일의 애니메이션 길이가 6~10s 정도이고 다른 재생 종류에 비해 SyncPoints 구간이 압도적으로 길어지기 때문이다.(SynPoints가 Progressive인 mp4는 key-frame 단위, fmp4인 DASH인 경우 fmp4 단위)
따라서 우선 Seek를 원하는 프레임을 찾으려면 6~10s 파일을 먼저 가져와야 합니다.이럴 때는 우선 시간이 걸린다.또한 나중에 세그먼트 뒤에 Seek하고 싶은 프레임이 있으면 거의 모든 프레임을 디코딩한 후 Skip을 버려야 합니다.
실제로 통신 환경이 좋은 환경(60Mbps 정도)에서 단의 전방과 후방에서 검색을 하면 단의 전방에서 검색을 하는 경우 상부의 sb(skipped buffer count)는 9로 검색하는 시간도 어느 정도 이르지만 단의 후방에서 검색을 하는 경우 sb는 198이다시크에 도착하는 시간도 아까보다 많이 걸렸다.
이해하기 어렵지만'장면의 마지막 찾기'는 영상이 멈췄다는 것을 알 수 있다.
실제로 seekTo () 를 읽는 것부터 첫 번째 프레임을 그리는 것까지'세그먼트의 시작 부분에서 찾기'는 85ms,'세그먼트의 마지막 찾기'는 757ms가 든다.
세그먼트의 첫 번째 찾기
단락의 마지막 찾기
이렇게 하면 통신 속도가 좋지 않은 환경에서 단락 파일(6~10s)을 얻는 시간도 다른 방송 종류보다 큰 영향을 미친다.
그러면 SeekParemeters를 이용해보는 건 어떨까요?
실제로 ExoPlayer는 HLS에서 SeekParameter를 지원하지 않습니다.
SyncPoints와 검색 위치가 너무 다르기 때문입니다.따라서 HLS는 매번 frame accurate seeking을 진행합니다.
총결산
ExoPlayer는
frame accurate seeking
를 사용합니다. 프레임을 어떻게 찾았습니까?ExoPlayer는 SyncPoints의 개념에 따라 찾아야 할 프레임을 찾았습니다.
SyncPoints는 프레임 등을 표시합니다. 그들은 검색 가능한 특정 구간을 구분하고 이 특정 프레임으로 구분된 구간에 따라 프레임을 검색할 수 있습니다.
그렇다면 검색 가능한 특정 구간을 구분할 수 있는 프레임은 어떤 프레임을 가리키나요?
이것은 흐름식 전송 프로토콜과 윤곽 형식에 달려 있다.
예를 들어 progressive에 재생되는 mp4의 경우
stbl
상자에서 키프레임의 위치를 확인할 수 있기 때문에 SyncPoints는 키프레임입니다.또한 fmp4에서 재생된 MPEG-DASH의 경우 SyncPoints는 fmp4로 구분된 구간이고, MPEG2-TS에서 재생된 HLS의 경우 SyncPoints는 각 TS 파일입니다.검색할 프레임을 찾으면 ExoPlayer는 이 구간에서 데이터를 디코더에 넣고 디코딩을 시작합니다.
여기서 주의해야 할 것은 seek의 프레임이 아니라 구간의 첫 번째 프레임에서 디코더에 쌓이는 것이다.따라서 ExoPlayer는 isDecodeOnly의 로고를 구간에서 시작하는 프레임부터seek 프레임 이전의 Buffer에 추가합니다.이 로고를 추가하면 디코더는 구간에서 시작하는 프레임부터seek 프레임 이전의 프레임을 디코딩하지만 디코딩 후의 프레임은 그리지 않고 skip입니다.
그런 다음 프레임 뒤에 있는 프레임을 디코딩하면 프레임이 Surface에 그려집니다.
(seek를 원하는 프레임 이전의 Key-Fame에서 왜 Decoder를 넣지 않았는지 모르겠다.)
SeekParameters
검색 과정은 검색할 프레임과 검색 프레임의 decode 과정을 통해 일정한 시간을 소비합니다.
SeekParameters는 검색 프로세스의 시간을 단축할 수 있습니다.
SeekParameters: EXACT, CLOSEST_SYNC, PREVIOUS_SUNC, NEXT_SYNC에는 네 가지가 있습니다.
EXACT는 지금까지 설명한 것
frame accurate seeking
이며, 그 외의 것은 찾아야 할 대상의 프레임을 SyncPoints로 분리하는 프레임으로 설정합니다.이렇게 하면 불필요한 인코딩 과정을 절약하고 찾을 수 있어 프레임 1을 표시하는 시간을 줄일 수 있다.다음은 구분된 점의 프레임을sync-frame로 읽습니다. 아까 SyncPoints의 정의를 보면 이sync-frame은 어떤 경우 Key-Fame이지만 재생 종류에 따라 때로는 Key-Fame 단위도 아니기 때문에 정확하게 말하면 아니기 때문입니다
key-frame accurate seeking
.SeekParameters
개요
EXACT
Default 검색 방법가장 가까운 프레임을 찾아라.
CLOSEST_SYNC
최근sync-frame을 찾습니다.
PREVIOUS_SYNC
마지막 sync-frame을 찾습니다.
NEXT_SYNC
최근sync-frame을 찾습니다.
HLS 검색이 느립니까?
ExoPlayer로 HLS의 흐름을 검색하면 다른 재생 종류에 비해 검색이 압도적으로 느립니다.
이는 일반적으로 TS 파일의 애니메이션 길이가 6~10s 정도이고 다른 재생 종류에 비해 SyncPoints 구간이 압도적으로 길어지기 때문이다.(SynPoints가 Progressive인 mp4는 key-frame 단위, fmp4인 DASH인 경우 fmp4 단위)
따라서 우선 Seek를 원하는 프레임을 찾으려면 6~10s 파일을 먼저 가져와야 합니다.이럴 때는 우선 시간이 걸린다.또한 나중에 세그먼트 뒤에 Seek하고 싶은 프레임이 있으면 거의 모든 프레임을 디코딩한 후 Skip을 버려야 합니다.
실제로 통신 환경이 좋은 환경(60Mbps 정도)에서 단의 전방과 후방에서 검색을 하면 단의 전방에서 검색을 하는 경우 상부의 sb(skipped buffer count)는 9로 검색하는 시간도 어느 정도 이르지만 단의 후방에서 검색을 하는 경우 sb는 198이다시크에 도착하는 시간도 아까보다 많이 걸렸다.
이해하기 어렵지만'장면의 마지막 찾기'는 영상이 멈췄다는 것을 알 수 있다.
실제로 seekTo () 를 읽는 것부터 첫 번째 프레임을 그리는 것까지'세그먼트의 시작 부분에서 찾기'는 85ms,'세그먼트의 마지막 찾기'는 757ms가 든다.
세그먼트의 첫 번째 찾기
단락의 마지막 찾기
이렇게 하면 통신 속도가 좋지 않은 환경에서 단락 파일(6~10s)을 얻는 시간도 다른 방송 종류보다 큰 영향을 미친다.
그러면 SeekParemeters를 이용해보는 건 어떨까요?
실제로 ExoPlayer는 HLS에서 SeekParameter를 지원하지 않습니다.
SyncPoints와 검색 위치가 너무 다르기 때문입니다.따라서 HLS는 매번 frame accurate seeking을 진행합니다.
총결산
Reference
이 문제에 관하여(Deep Understanding of Seek), 우리는 이곳에서 더 많은 자료를 발견하고 링크를 클릭하여 보았다 https://qiita.com/takusemba/items/9abd90187d8f55d1c921텍스트를 자유롭게 공유하거나 복사할 수 있습니다.하지만 이 문서의 URL은 참조 URL로 남겨 두십시오.
우수한 개발자 콘텐츠 발견에 전념 (Collection and Share based on the CC Protocol.)