prevent color conversion for shm src/sink
Locked
 
|
Hi all,
I pipe an 8 bit greyscale video stream through gstreamer. To allow another process to access the gstreamer results, I use shmsrc / shmsink. But to get the data piped through properly, I have to push the format to video/x-raw,format=(string)BGRx, otherwise the transfer through shm doesn't seem to work properly. This cost a big pile of CPU power for the upconversion and wastes a lot of RAM (only embedded device). Any idea what could be wrong here? And - if you have alternative approaches how to connect two independently running gstreamer processes (same device), just let me know, I'd be happy to improve my approach here... Thanks! Best regards, Erik _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
|
|
On Mon, Apr 20, 2020 at 10:45 AM Erik Rull <[hidden email]> wrote: I pipe an 8 bit greyscale video stream through gstreamer. To allow another You shouldn't have to convert to BGRx to use shmsrc/shmsink, those elements don't even really have the concept of video, they're agnostic to it, they just see buffers that need to be sent. Can you share your sending and receiving pipeline? And - if you have alternative approaches how to connect two independently Shared memory is zero-copy, so has the best performance. What kind of throughput are you using? And what platform? -Josh _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
|
|
Hi Josh,
thanks for the fast reply - and yes, I also understood it that way that the shm is just a memory buffer of "whatever goes in, goes out". Josh Doe wrote: > You shouldn't have to convert to BGRx to use shmsrc/shmsink, those elements > don't even really have the concept of video, they're agnostic to it, they just > see buffers that need to be sent. Can you share your sending and receiving pipeline? > Shared memory is zero-copy, so has the best performance. What kind of throughput > are you using? And what platform? > > -Josh CPU is an IMX embedded device, the rest is kind-of LFS. My pipeline parts look like this - the appsrc / appsink encapsulates some image processing (special overlay, reformatting, etc.) that I could not solve with gstreamer - the processing time is far less than 100msec inside and the output is grayscale: aravissrc camera-name=x.x.x.x num-buffers=10 exposure=100000 gain-auto=0 ! video/x-raw,format=GRAY8,width=640,height=512,framerate=8/1 ! videoconvert ! videobalance contrast=1.4 brightness=-0.3 contrast=1.8 ! videoconvert ! video/x-raw,format=GRAY8 ! appsink name=sink max-buffers=10 drop=1 appsrc name=src stream-type=0 is-live=1 max-bytes=10000000 caps=video/x-raw,format=(string)GRAY8,framerate=8/1,width=401,height=404 ! shmsink render-delay=0 socket-path=/tmp/pad_shm shm-size=10000000 wait-for-connection=0 max-lateness=500000000 buffer-time=0 shmsrc socket-path=/tmp/pad_shm is-live=1 ! video/x-raw,format=(string)BGRx,framerate=(fraction)8/1,pixel-aspect-ratio=(fraction)1/1,interlace-mode=(string)progressive,width=401,height=404 ! videoconvert ! identity name=identity ! ximagesink max-lateness=500000000 name=sink Maybe I have additional errors somewhere else in the pipeline... But due to the fact that my appsrc exposes an 8bit image, I would not expect shmsrc to get out something differently... At the end - the displayed image is actually grey :-) The identity at the end I use to count the number of images displayed. I generate some additional output between appsink and appsrc if I map that right beside the image, the image is delayed by ~ 2 seconds... Thanks! Best regards, Erik _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
|
|
Hi Josh,
sorry - one item is wrong on my side, but if I "correct" it, I don't see anything at all on the ximagesink! It's already some time ago, I wrote this part of code for appsrc, that's why I did not remember all bits and pieces ;-) So my corrected pipeline now actually dumps out 8 bit items in appsrc (also internally in the appsrc implementation!): aravissrc camera-name=172.17.48.35 num-buffers=10 exposure=100000 gain-auto=0 ! video/x-raw,format=GRAY8,width=640,height=512,framerate=8/1 ! videoconvert ! videobalance contrast=1.4 brightness=-0.3 contrast=1.8 ! videoconvert ! video/x-raw,format=GRAY8 ! appsink name=sink max-buffers=10 drop=1 (same as before) appsrc name=src stream-type=0 is-live=1 max-bytes=10000000 caps=video/x-raw,format=(string)GRAY8,framerate=8/1,width=401,height=404 ! shmsink render-delay=0 socket-path=/tmp/pad_shm shm-size=10000000 wait-for-connection=0 max-lateness=500000000 buffer-time=0 (internally corrected to real GRAY8 bit) shmsrc socket-path=/tmp/pad_shm is-live=1 ! video/x-raw,format=(string)GRAY8,framerate=(fraction)8/1,pixel-aspect-ratio=(fraction)1/1,interlace-mode=(string)progressive,width=401,height=404 ! videoconvert ! identity name=identity ! ximagesink max-lateness=500000000 name=sink (adapted to GRAY8) Any ideas how to proceed? identity reports images (which is my pipeline image counter)... Thanks a lot! Best regards, Erik Erik Rull wrote: > Hi Josh, > > thanks for the fast reply - and yes, I also understood it that way that the shm > is just a memory buffer of "whatever goes in, goes out". > > Josh Doe wrote: >> You shouldn't have to convert to BGRx to use shmsrc/shmsink, those elements >> don't even really have the concept of video, they're agnostic to it, they just >> see buffers that need to be sent. Can you share your sending and receiving pipeline? > >> Shared memory is zero-copy, so has the best performance. What kind of throughput >> are you using? And what platform? >> >> -Josh > > CPU is an IMX embedded device, the rest is kind-of LFS. > > My pipeline parts look like this - the appsrc / appsink encapsulates some image > processing (special overlay, reformatting, etc.) that I could not solve with > gstreamer - the processing time is far less than 100msec inside and the output > is grayscale: > > aravissrc camera-name=x.x.x.x num-buffers=10 exposure=100000 gain-auto=0 ! > video/x-raw,format=GRAY8,width=640,height=512,framerate=8/1 ! videoconvert ! > videobalance contrast=1.4 brightness=-0.3 contrast=1.8 ! videoconvert ! > video/x-raw,format=GRAY8 ! appsink name=sink max-buffers=10 drop=1 > > appsrc name=src stream-type=0 is-live=1 max-bytes=10000000 > caps=video/x-raw,format=(string)GRAY8,framerate=8/1,width=401,height=404 ! > shmsink render-delay=0 socket-path=/tmp/pad_shm shm-size=10000000 > wait-for-connection=0 max-lateness=500000000 buffer-time=0 > > shmsrc socket-path=/tmp/pad_shm is-live=1 ! > video/x-raw,format=(string)BGRx,framerate=(fraction)8/1,pixel-aspect-ratio=(fraction)1/1,interlace-mode=(string)progressive,width=401,height=404 > ! videoconvert ! identity name=identity ! ximagesink max-lateness=500000000 > name=sink > > Maybe I have additional errors somewhere else in the pipeline... > > But due to the fact that my appsrc exposes an 8bit image, I would not expect > shmsrc to get out something differently... > At the end - the displayed image is actually grey :-) > The identity at the end I use to count the number of images displayed. > I generate some additional output between appsink and appsrc if I map that right > beside the image, the image is delayed by ~ 2 seconds... > > Thanks! > > Best regards, > > Erik > > _______________________________________________ > gstreamer-devel mailing list > [hidden email] > https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel > gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
«
Return to GStreamer-devel
|
1 view|%1 views
| Free forum by Nabble | Edit this page |