Issues and suggestion for shm in Gstreamer in Jetson Nano

Akhil Ashref akhilashrefnc at gmail.com
Mon Jan 11 10:31:06 UTC 2021


As of now I have the given below pipeline working perfectly on nano

Source: nvarguscamerasrc sensor-id=1 sensor-mode=4 do-timestamp=true !
video/x-raw(memory:NVMM), width=1920, height=1080, framerate=30/1,
format=NV12 !
nvvidconv flip-method={1} ! video/x-raw, format=NV12 ! appsink name=sink0
emit-signals=true sync=false"

SHM pipe: appsrc name=src0 do-timestamp=true ! video/x-raw, width={0:d},
height={1:d}, framerate=30/1, format=NV12 ! shmsink sync=false
socket-path={2:s}

Recorder pipe: shmsrc socket-path={0:s} name=src0 do-timestamp=true ! queue
! video/x-raw, width={1:d}, height={2:d}, framerate=30/1, format=NV12 !
nvvidconv ! video/x-raw(memory:NVMM), format=NV12 ! nvv4l2h265enc
bitrate={3:d} ! video/x-h265 ! h265parse name=parse0 ! splitmuxsink
name=sink0 location={4:s} max-size-bytes={5:d} max-size-time={6:d}
muxer=mp4mux

There are multiple SHM pipe connected to source with different sockets
connected to the recorder. This multiple recorder save multiple sets of mp4
videos with different FPS without any issues. I have 60,30,10 … fps videos
saved

Now I want to test the above pipeline with video sets, specifically input 60
fps videos sets and stream through the shared memory and finally save as the
recorder does above.

For that with out shm this is what I made:
splitfilesrc location='data/*.mp4' ! qtdemux ! queue ! h265parse !
nvv4l2decoder ! videorate! nvvidconv !
'video/x-raw(memory:NVMM),width=1920,height=1080, framerate=10/1'!
nvv4l2h265enc bitrate = 12000000 ! h265parse name=parse0 ! splitmuxsink
name=sink0 location='any%04d.mp4' max-size-bytes=10000000000
max-size-time=10000000000 muxer=mp4mux

Now this works as expected for one file but for some reason the pipeline
breaks soon after. From the documentation splitfilesrc should read
everything under “data/” but it doesn’t. It just reads the one file. Is the
problem unique to nano? Anything I am missing or mistake on my part?

Next question: Trying the same for one large video file, replacing above
part in source, the pipeline stops too quickly and recorder doesn’t have
time to load(my assumption). wait-for-connection is true by default for
shmsink so shouldn’t the source wait till recorder is connected? Any mistake
here or any better way to tackle/approach this?



--
Sent from: http://gstreamer-devel.966125.n4.nabble.com/


More information about the gstreamer-devel mailing list