Issues and suggestion for shm in Gstreamer in Jetson Nano

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view

Issues and suggestion for shm in Gstreamer in Jetson Nano

Akhil Ashref
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

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}

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

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:
gstreamer-devel mailing list
[hidden email]