2016-08-11 3 views
0

동시에 여러 gstreamer 프로세스를 실행할 때 appsrc에서 filesink로 저장하는 데 문제가 있습니다. gstreamer 프로세스 중 하나만 올바르게 쓰고 나머지는 모두 거의 빈 파일을 작성합니다. 파일 링크 작업 중에 경합을 쓴 것으로 보입니다.appsrc에서 여러 개의 파일 싱크를 동시에 쓸 수 없습니다.

참고 : MAC OS 10.11.6에서 python3 (v3.5.2)과 함께 gstreamer1.0 (v1.8.2)을 사용하고 있습니다. 나는 하나의 비디오 스트림에서 프레임 읽고있다, 배경에

크기 1920x800x3의 BGR의 NumPy와 배열에 각 프레임을 변환하고, 순환 버퍼의 각 프레임을 저장 :

여기에 내 코드가 실제로 무엇을하는지입니다 . 이 순환 버퍼에서 프레임을 읽고 프레임을 바이트 스트림으로 변환 한 다음이 스트림을 appsrc에 공급하는 "gstreamer_writer 함수"를 만들었습니다.

새로운 다중 프로세스 (다중 처리. 프로세스)를 인스턴스화하고 이것을 "gstreamer_writer 함수"로 지정하여 작동합니다. 이것은 단일 다중 프로세스/함수 호출에 대해 완벽하게 작동합니다. Appsrc 올바르게 바이트 스트림을 공급하고 나는이 BGR은 다음 gstreamer를 파이프 라인을 사용하여 H264 인코딩으로 MP4로 프레임 저장 : 나는 두 개 이상의 multiprocesses을 인스턴스화하고 기능에 중 하나만을 가리키는 경우, 그러나

appsrc format=3 name=app emit-signals=true do-timestamp=true is-live=true blocksize=4608000 max-bytes=0 caps=video/x-raw,format=BGR,width=1920,height=800 ! videoconvert ! video/x-raw,format=I420,width=1920,height=800 ! vtenc_h264 ! mp4mux ! filesink location=test1.mp4 

을 파일이 제대로 작동합니다. 예를 들어, 하나는 "test1.mp4"에 쓰고 다른 하나는 "test2.mp4"에 쓰면 비디오 중 하나가 올바르게 쓰여지고 다른 하나는 실패하고 거의 비어있는 mp4 (~ 500kb)를 쓰게됩니다. 항상 같은 mp4는 아니지만, test1.mp4가 정확하게 쓰여지고 50 %의 시간 동안 test2.mp4가 올바르게 쓰여집니다. 어떤 종류의 경쟁 상태이거나 mp4가 제대로 파일에 기록되지 못하게하는 경합이있는 것 같습니다.

주목할 점은 각 다중 프로세스가 동일한 링 버퍼에서 동일한 프레임에 액세스한다는 것입니다. 나는 이것이 gstreamer에 문제를 일으킬 수 있다고 생각했다. 그러나 파일을 파일로 쓰는 대신 autovideosink로 스트림을 표시하면 원하는만큼 스트림/다중 프로세스를 표시 할 수 있습니다. 이것은 데이터가 파이프 라인을 통해 올바르게 전달되고 쓰기 단계에서만 실패 함을 의미합니다. 누군가가 내가이 문제를 해결할 수있는 방법에 대한 제안 사항이있는 경우

appsrc format=3 name=app emit-signals=true do-timestamp=true is-live=true blocksize=4608000 max-bytes=0 caps=video/x-raw,format=BGR,width=1920,height=800 ! videoconvert ! video/x-raw,format=I420,width=1920,height=800 ! vtenc_h264 ! avdec_h264 ! autovideosink 

내가 그것을 감사하겠습니다 : 나는 gstreamer를 명령을 사용하여이 테스트. 나는 그것이 간단한 변화 일 것이지만 당신은 gstreamer로 결코 알지 못할 것입니다!

감사합니다.

답변

0

너무 논평을 한, 내가 올바른 생각하면이 문제를 해결할 수 있습니다 ..

filesink 전에 큐를 추가 소모 요소 앞에 +가 버퍼를합니다

appsrc format=3 name=app emit-signals=true do-timestamp=true is-live=true blocksize=4608000 max-bytes=0 caps=video/x-raw,format=BGR,width=1920,height=800 ! videoconvert ! video/x-raw,format=I420,width=1920,height=800 ! queue ! vtenc_h264 ! mp4mux ! queue ! filesink location=test1.mp4 

큐는 두 가지 기능이 있습니다 (어떤 인코더가 - 인코딩을 시작하기 전에 많은 프레임이 필요합니다) + 새로운 스레드로 추가 처리 - 파일 싱크가 새로운 스레드에서 데이터를 처리하도록합니다.

HTH

+0

@ inplsky! 불행히도이 두 대기열을 추가해도 문제가 해결되지 않았습니다. 한 프로세스는 즉시 파일 쓰기를 시작하고 다른 프로세스는 0MB로 계속 쓰기 시작합니다. 오류 : GST_PADS gstpad.c : 3279 : gboolean gst_pad_query_latency_default (GstPad *, GstQuery *) : 대기 시간이 최대 대기 시간보다 깁니다. 또한 다음과 같은 오류가 발생합니다. vtenc vtenc.c : 807 : gst_vtenc_create_session : VTCompressionSessionCreate() 반환 : -12915 –

관련 문제