저는 스트림 처리 없이 RTMP 스트림을 HLS(재생 목록 파일 저장)로 캡처하기 위해 FFMPEG를 사용하고 있습니다. 그냥 복사하면 됩니다. 이 설정 덕분에 메모리와 CPU 소비가 30% 이하인 상태에서 수십 개의 프로세스(최대 80개까지 시도)를 실행할 수 있었습니다.
이것은 내 명령입니다:
ffmpeg -i <RTMP__STREAM_URL> -hls_init_time 10 -hls_time 10 -hls_list_size 0 -f hls -strftime 1 -hls_segment_filename '%H-%M-%S-%s.ts' -hls_flags split_by_time -codec:v copy -codec:a copy ./play$(date -d "today" +"%M%S-%s").m3u8
안타깝게도 프로세스 수가 증가함에 따라 일부 HLS 세그먼트(HLS는 재생 목록 파일과 파일을 구성하는 세그먼트로 구성됨)가 손실되기 시작했습니다. 예를 들어 HLS는 0:00부터 0:40까지 잘 재생되지만 0:40에 10초 동안 정지되고(제 클립의 길이는 10초입니다) 0:50에 정지 해제됩니다.
FFMPEG 프로세스를 20개 실행할 경우 손실률은 약 5%이고, 프로세스 80개를 실행할 경우 손실률은 50%에 가깝습니다.
저는 Ubuntu 22.x와 다양한 머신 유형을 사용하여 AWS EC2 인스턴스에서 이러한 벤치마크를 수행하고 있습니다. 오류 빈도는 머신 유형에 관계없이 동일하므로 CPU나 메모리와는 관련이 없다고 가정합니다.
나는 이것이 I/O 및 파일 쓰기(EC2 또는 Ubuntu 설정)와 관련이 있다고 생각합니다.
어떤 아이디어가 있나요?
답변1
해결되었습니다.
이는 리소스나 성능과는 아무 관련이 없는 것으로 나타났습니다. 프로세스가 서로의 세그먼트를 덮어쓰기 때문에 비디오가 정지됩니다.
확실히 밀리초 단위의 타임스탬프는 충분히 고유하지 않습니다. 저는 무작위로 생성된 값을 각 프로세스에 추가한 다음 이를 파일 이름에 사용하여 이 문제를 해결했습니다. 물론 각 프로세스마다 다른 디렉터리를 사용하면 동일한 효과를 얻을 수 있습니다.
100개의 프로세스가 있어도 다음 명령은 완벽하게 작동합니다.
ffmpeg -i <RTMP_STREAM_URL> -hls_init_time 10 -hls_time 10 -hls_list_size 0 -f hls -strftime 1 -hls_segment_filename $(rand)'%H-%M-%S-%s.ts' -hls_flags split_by_time -codec:v copy -codec:a copy play_$(rand)_$(date -d "today" +"%M%S-%s").m3u8 </dev/null >/dev/null 2>&1 &