I'm trying to show the video from an input camera in my display using
v4l2src. Unfortunately, the driver of the cameras module is not very good, and in fact I have had to fix a few things to advance. But still I haven't managed to show the image in the display. My device have an ARM based Allwinner A20 processor, and use this driver for the cameras input: https://github.com/meantone/sunxi-tvin I'm trying this pipeline: gst-launch-1.0 v4l2src device=/dev/video1 ! video/x-raw,format=NV12,width=720,height=576 ! videoconvert ! xvimagesink I know that the driver works because using a very basic demo program with the same configuration (NV12 720x576) I can see camera images. I attach 2 files: one with gstreamer output using GST_DEBUG=*v4l2*:6 and another with driver debug messages, let's see if someone can give me any clue about what's failing here. Note: there are some messages at the beginning about driver don't reporting valid framesizes. However, I think this is not important because later it seems to configure the framesize correctly, and I know that this framesize is OK for the driver. _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
I have managed to solve a problem: it seems that the sprite was not well reported by the driver (it said it was 1080 instead of 720). Now I think it gives the correct values for a 720x576px NV12 frame: sprite 720, size 622080 However, I still doesn't have a good output, and I don't know what to do to find what's wrong (I have no previous experience with video nor gstreamer). With this pipeline: gst-launch-1.0 v4l2src device=/dev/video1 !
video/x-raw,format=NV12,width=720, I only get an output with very colorful lines (almost horizontal lines). I attach the output of the driver and gstreamer with
GST_DEBUG=*videosink*:6,*imagesink*:6,*v4l2*:6 Any hint? Thanks! El 19/04/18 a las 12:07, Iñigo Huguet
escribió:
I'm trying to show the video from an input camera in my display using v4l2src. _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel gst-output-20180423.txt (152K) Download Attachment tvd-output-20180423.txt (10K) Download Attachment |
On Mon, 23 Apr 2018 16:26:42 +0200
Iñigo Huguet <[hidden email]> wrote: > I have managed to solve a problem: it seems that the sprite was not well > reported by the driver (it said it was 1080 instead of 720). Now I think > it gives the correct values for a 720x576px NV12 frame: sprite 720, size > 622080 > > However, I still doesn't have a good output, and I don't know what to do > to find what's wrong (I have no previous experience with video nor > gstreamer). > > With this pipeline: gst-launch-1.0 v4l2src device=/dev/video1 ! > video/x-raw,format=NV12,width=720, > height=576 ! videoconvert ! xvimagesink sync=false > > I only get an output with very colorful lines (almost horizontal lines). > > I attach the output of the driver and gstreamer with > GST_DEBUG=*videosink*:6,*imagesink*:6,*v4l2*:6 > > Any hint? Thanks! > If you cannot trust the driver to report the correct data format (I am thinking to the pixelformat in particular), then GStreamer videoconvert won't be able to use the caps in any meaningful way. You could analyze a raw frame to confirm that it's actually NV12. A sample pipeline which (hopefully) dumps one frame is: gst-launch-1.0 v4l2src num-buffers=1 device=/dev/video1 ! filesink location=raw_frame.bin Upload the raw data somewhere and maybe someone will take a look if they have time. Ciao, Antonio -- Antonio Ospite https://ao2.it https://twitter.com/ao2it A: Because it messes up the order in which people normally read text. See http://en.wikipedia.org/wiki/Posting_style Q: Why is top-posting such a bad thing? _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
Hi.
I have gotten one frame as you told me gst-launch-1.0 v4l2src num-buffers=1 device=/dev/video1 ! video/x-raw,format=NV12,width=720,height=576 ! filesink location=raw_frame.bin Then, in my computer, I converted it to png: gst-launch-1.0 -v filesrc location=raw_frame.bin ! videoparse width=720 height=576 format=GST_VIDEO_FORMAT_NV12 ! videoconvert ! pngenc ! filesink location=raw_frame.png I can see the .png image correctly, so it seems that the driver outputs NV12. What can I try now? Maybe I need any additional plugin? (I'm using a custom build using Buildroot so I don't have all plugins installed) El 23/04/18 a las 17:09, Antonio Ospite escribió: > On Mon, 23 Apr 2018 16:26:42 +0200 > Iñigo Huguet <[hidden email]> wrote: > >> I have managed to solve a problem: it seems that the sprite was not well >> reported by the driver (it said it was 1080 instead of 720). Now I think >> it gives the correct values for a 720x576px NV12 frame: sprite 720, size >> 622080 >> >> However, I still doesn't have a good output, and I don't know what to do >> to find what's wrong (I have no previous experience with video nor >> gstreamer). >> >> With this pipeline: gst-launch-1.0 v4l2src device=/dev/video1 ! >> video/x-raw,format=NV12,width=720, >> height=576 ! videoconvert ! xvimagesink sync=false >> >> I only get an output with very colorful lines (almost horizontal lines). >> >> I attach the output of the driver and gstreamer with >> GST_DEBUG=*videosink*:6,*imagesink*:6,*v4l2*:6 >> >> Any hint? Thanks! >> > If you cannot trust the driver to report the correct data format (I am > thinking to the pixelformat in particular), then GStreamer videoconvert > won't be able to use the caps in any meaningful way. > > You could analyze a raw frame to confirm that it's actually NV12. > > A sample pipeline which (hopefully) dumps one frame is: > > gst-launch-1.0 v4l2src num-buffers=1 device=/dev/video1 ! filesink location=raw_frame.bin > > Upload the raw data somewhere and maybe someone will take a look > if they have time. > > Ciao, > Antonio > _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
Have you try to use playbin2 instead?
Something like 'gst-launch-1.0 playbin2 uri=v4l2:///dev/video1'. If its works, have a look into the log and see what playbin2 had done. Bernhard -----Ursprüngliche Nachricht----- Von: gstreamer-devel [mailto:[hidden email]] Im Auftrag von Iñigo Huguet Gesendet: Dienstag, 24. April 2018 11:13 An: Antonio Ospite; [hidden email] Betreff: Re: Displaying camera not working Hi. I have gotten one frame as you told me gst-launch-1.0 v4l2src num-buffers=1 device=/dev/video1 ! video/x-raw,format=NV12,width=720,height=576 ! filesink location=raw_frame.bin Then, in my computer, I converted it to png: gst-launch-1.0 -v filesrc location=raw_frame.bin ! videoparse width=720 height=576 format=GST_VIDEO_FORMAT_NV12 ! videoconvert ! pngenc ! filesink location=raw_frame.png I can see the .png image correctly, so it seems that the driver outputs NV12. What can I try now? Maybe I need any additional plugin? (I'm using a custom build using Buildroot so I don't have all plugins installed) El 23/04/18 a las 17:09, Antonio Ospite escribió: > On Mon, 23 Apr 2018 16:26:42 +0200 > Iñigo Huguet <[hidden email]> wrote: > >> I have managed to solve a problem: it seems that the sprite was not well >> reported by the driver (it said it was 1080 instead of 720). Now I think >> it gives the correct values for a 720x576px NV12 frame: sprite 720, size >> 622080 >> >> However, I still doesn't have a good output, and I don't know what to do >> to find what's wrong (I have no previous experience with video nor >> gstreamer). >> >> With this pipeline: gst-launch-1.0 v4l2src device=/dev/video1 ! >> video/x-raw,format=NV12,width=720, >> height=576 ! videoconvert ! xvimagesink sync=false >> >> I only get an output with very colorful lines (almost horizontal lines). >> >> I attach the output of the driver and gstreamer with >> GST_DEBUG=*videosink*:6,*imagesink*:6,*v4l2*:6 >> >> Any hint? Thanks! >> > If you cannot trust the driver to report the correct data format (I am > thinking to the pixelformat in particular), then GStreamer videoconvert > won't be able to use the caps in any meaningful way. > > You could analyze a raw frame to confirm that it's actually NV12. > > A sample pipeline which (hopefully) dumps one frame is: > > gst-launch-1.0 v4l2src num-buffers=1 device=/dev/video1 ! filesink > > Upload the raw data somewhere and maybe someone will take a look > if they have time. > > Ciao, > Antonio > _______________________________________________ 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 |
I don't have playbin2, but I do have playbin.
It doesn't work right now, I think it is because the driver doesn't report correctly its available framesizes (width X height). That's why I had to specify them with video/x-raw width=720,height=576 There is any way to specify the framesize with playbin? If not, I will try to fix the driver. El 24/04/18 a las 12:45, Bernhard Graaf escribió: > Have you try to use playbin2 instead? > Something like 'gst-launch-1.0 playbin2 uri=v4l2:///dev/video1'. > If its works, have a look into the log and see what playbin2 had done. > > Bernhard > > -----Ursprüngliche Nachricht----- > Von: gstreamer-devel [mailto:[hidden email]] > Im Auftrag von Iñigo Huguet > Gesendet: Dienstag, 24. April 2018 11:13 > An: Antonio Ospite; [hidden email] > Betreff: Re: Displaying camera not working > > Hi. > > I have gotten one frame as you told me > > gst-launch-1.0 v4l2src num-buffers=1 device=/dev/video1 ! > video/x-raw,format=NV12,width=720,height=576 ! filesink > location=raw_frame.bin > > Then, in my computer, I converted it to png: > > gst-launch-1.0 -v filesrc location=raw_frame.bin ! videoparse width=720 > height=576 format=GST_VIDEO_FORMAT_NV12 ! videoconvert ! pngenc ! > filesink location=raw_frame.png > > I can see the .png image correctly, so it seems that the driver outputs > NV12. What can I try now? Maybe I need any additional plugin? (I'm using > a custom build using Buildroot so I don't have all plugins installed) > > El 23/04/18 a las 17:09, Antonio Ospite escribió: >> On Mon, 23 Apr 2018 16:26:42 +0200 >> Iñigo Huguet <[hidden email]> wrote: >> >>> I have managed to solve a problem: it seems that the sprite was not well >>> reported by the driver (it said it was 1080 instead of 720). Now I think >>> it gives the correct values for a 720x576px NV12 frame: sprite 720, size >>> 622080 >>> >>> However, I still doesn't have a good output, and I don't know what to do >>> to find what's wrong (I have no previous experience with video nor >>> gstreamer). >>> >>> With this pipeline: gst-launch-1.0 v4l2src device=/dev/video1 ! >>> video/x-raw,format=NV12,width=720, >>> height=576 ! videoconvert ! xvimagesink sync=false >>> >>> I only get an output with very colorful lines (almost horizontal lines). >>> >>> I attach the output of the driver and gstreamer with >>> GST_DEBUG=*videosink*:6,*imagesink*:6,*v4l2*:6 >>> >>> Any hint? Thanks! >>> >> If you cannot trust the driver to report the correct data format (I am >> thinking to the pixelformat in particular), then GStreamer videoconvert >> won't be able to use the caps in any meaningful way. >> >> You could analyze a raw frame to confirm that it's actually NV12. >> >> A sample pipeline which (hopefully) dumps one frame is: >> >> gst-launch-1.0 v4l2src num-buffers=1 device=/dev/video1 ! filesink > location=raw_frame.bin >> Upload the raw data somewhere and maybe someone will take a look >> if they have time. >> >> Ciao, >> Antonio >> > _______________________________________________ > 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 _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
Just my 2 cents, if you are sure that you know that the data is being read correctly you can use "rawvideoparse" to set the correct caps of the buffers. It will also merge partial buffers, so make sure you include the correct strides for the buffers and also make sure the chromaticities for the buffers are set correctly, otherwise you will get discoloration on the output. On Tue, Apr 24, 2018 at 3:23 PM, Iñigo Huguet <[hidden email]> wrote: I don't have playbin2, but I do have playbin. _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
Another "easy" check is to use v4l2src num-buffers=1 ! fakesink dump=1 and check that the byte dump is equal to the sprite data dump On Tue, Apr 24, 2018 at 4:40 PM, Dimitrios Katsaros <[hidden email]> wrote:
_______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
Hi Dimitrios. Sorry but I don't know how to do what you say, this is my first time with video processing and with gstreamer too. What do you mean with the sprite data dump? How must I use rawvideoparse, can you tell me the pipeline command? How do I set the chromacities? Thanks! El 24/04/18 a las 16:41, Dimitrios
Katsaros escribió:
_______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
In reply to this post by Iñigo Huguet
Le mar. 24 avr. 2018 09:27, Iñigo Huguet <[hidden email]> a écrit : I don't have playbin2, but I do have playbin. If that is an option for you, then it's best thing to do. By the way, are you aware of the v4l2-compliance test ? This test, which is part of v4l2-utils helps a lot to ensure your driver is usable across most userapace.
_______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
I intended to fix it later because this particular thing didn't seem to be the problem. But maybe I start with it today or on monday. I was aware of v4l2-compliance, thanks. In the meantime, I have done some findings: I used this command in my device: gst-launch-1.0 v4l2src device=/dev/video1 ! video/x-raw,format=NV12,width=720,height=576 ! filesink location=raw_video.bin Then, I transfered raw_video.bin to my computer and used this command: gst-launch-1.0 filesrc location=raw_video.bin ! videoparse width=720 height=576 format=GST_VIDEO_FORMAT_NV12 ! videoconvert ! autovideosink This way, I can see the image OK, not only lot of lines of random
colors. So I concluded that the problem in my device must be in
videoconvert or in xvimagesink, not in the cameras driver. gst-launch-1.0 v4l2src device=/dev/video1 ! video/x-raw,format=NV12,width=720,height=576 ! videoconvert ! fbdevsink sync=false I can see the image OK. I still don't know if the problem is in videoconvert, in xvimagesink, or in both. However, I can't use fbdevsink because it interferes with X11, trying both of them to "take control" of the framebuffer. Any hint about what can I try to find out what's failing and how to solve it? Also, I have another problem. Only one of every 7 buffers seems to be updated with a new frame, the other 6 remains with the first fame they captured at the beginning, so I have a video of the same sequence of 6 frames repeating all time the same and one single frame that seems to be correct between each 6 frames sequence. This problem could be related with the driver, but it's strange because with the demo program this didn't happen. El 25/04/18 a las 15:26, Nicolas
Dufresne escribió:
_______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
Le vendredi 27 avril 2018 à 11:17 +0200, Iñigo Huguet a écrit :
> gst-launch-1.0 filesrc location=raw_video.bin ! videoparse width=720 > height=576 format=GST_VIDEO_FORMAT_NV12 ! videoconvert ! > autovideosink > This way, I can see the image OK, not only lot of lines of random > colors. So I concluded that the problem in my device must be in > videoconvert or in xvimagesink, not in the cameras driver. > My device is using an Allwinner A20 SoC. This SoC uses the > framebuffer to output graphics, even using X11. So I installed > fbdevsink plugin and tried this command: > > gst-launch-1.0 v4l2src device=/dev/video1 ! video/x- > raw,format=NV12,width=720,height=576 ! videoconvert ! fbdevsink > sync=false > > I can see the image OK. I still don't know if the problem is in > videoconvert, in xvimagesink, or in both. However, I can't use > fbdevsink because it interferes with X11, trying both of them to > "take control" of the framebuffer. Any hint about what can I try to > find out what's failing and how to solve it? It's more likely a bug in XV driver. Make sure you use the very latest upstream code there. > > Also, I have another problem. Only one of every 7 buffers seems to be > updated with a new frame, the other 6 remains with the first fame > they captured at the beginning, so I have a video of the same > sequence of 6 frames repeating all time the same and one single frame > that seems to be correct between each 6 frames sequence. Looks familiar, but something that would have been fixed a long time ago. Which GStreamer version are you running ? Nicolas _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
It is the version included with Buildroot: 1.12.3.
With XV driver you mean an X11 driver, right? My device use xf86-video-fbturbo, which is based on xf86-video-fbdev, adding some optimizations and hardware accelerations for Allwinner SoC. It is supposed to have XV support. I'm pretty sure that this SoC uses (or admit) NV12 format in its framebuffer because demo program writes to the framebuffer in NV12 format. (as I said, framebuffer is used to display graphics, even with X11). That makes me think that the fbturbo driver should accept NV12 buffers as input for XV, but I don't know how to test it. El 27/04/18 a las 13:38, Nicolas Dufresne escribió: > Le vendredi 27 avril 2018 à 11:17 +0200, Iñigo Huguet a écrit : >> gst-launch-1.0 filesrc location=raw_video.bin ! videoparse width=720 >> height=576 format=GST_VIDEO_FORMAT_NV12 ! videoconvert ! >> autovideosink >> This way, I can see the image OK, not only lot of lines of random >> colors. So I concluded that the problem in my device must be in >> videoconvert or in xvimagesink, not in the cameras driver. >> My device is using an Allwinner A20 SoC. This SoC uses the >> framebuffer to output graphics, even using X11. So I installed >> fbdevsink plugin and tried this command: >> >> gst-launch-1.0 v4l2src device=/dev/video1 ! video/x- >> raw,format=NV12,width=720,height=576 ! videoconvert ! fbdevsink >> sync=false >> >> I can see the image OK. I still don't know if the problem is in >> videoconvert, in xvimagesink, or in both. However, I can't use >> fbdevsink because it interferes with X11, trying both of them to >> "take control" of the framebuffer. Any hint about what can I try to >> find out what's failing and how to solve it? > It's more likely a bug in XV driver. Make sure you use the very latest > upstream code there. > >> Also, I have another problem. Only one of every 7 buffers seems to be >> updated with a new frame, the other 6 remains with the first fame >> they captured at the beginning, so I have a video of the same >> sequence of 6 frames repeating all time the same and one single frame >> that seems to be correct between each 6 frames sequence. > Looks familiar, but something that would have been fixed a long time > ago. Which GStreamer version are you running ? > > Nicolas > _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
I have to say that I have had to add sync=false to the videosink because
if not lot of frames were reported to being dropped because of the source "being late" with the timestamps. May this be related to this problem of the frames that retain old content? El 27/04/18 a las 13:56, Iñigo Huguet escribió: > It is the version included with Buildroot: 1.12.3. > > With XV driver you mean an X11 driver, right? My device use > xf86-video-fbturbo, which is based on xf86-video-fbdev, adding some > optimizations and hardware accelerations for Allwinner SoC. It is > supposed to have XV support. > > I'm pretty sure that this SoC uses (or admit) NV12 format in its > framebuffer because demo program writes to the framebuffer in NV12 > format. (as I said, framebuffer is used to display graphics, even with > X11). That makes me think that the fbturbo driver should accept NV12 > buffers as input for XV, but I don't know how to test it. > > > El 27/04/18 a las 13:38, Nicolas Dufresne escribió: >> Le vendredi 27 avril 2018 à 11:17 +0200, Iñigo Huguet a écrit : >>> gst-launch-1.0 filesrc location=raw_video.bin ! videoparse width=720 >>> height=576 format=GST_VIDEO_FORMAT_NV12 ! videoconvert ! >>> autovideosink >>> This way, I can see the image OK, not only lot of lines of random >>> colors. So I concluded that the problem in my device must be in >>> videoconvert or in xvimagesink, not in the cameras driver. >>> My device is using an Allwinner A20 SoC. This SoC uses the >>> framebuffer to output graphics, even using X11. So I installed >>> fbdevsink plugin and tried this command: >>> >>> gst-launch-1.0 v4l2src device=/dev/video1 ! video/x- >>> raw,format=NV12,width=720,height=576 ! videoconvert ! fbdevsink >>> sync=false >>> >>> I can see the image OK. I still don't know if the problem is in >>> videoconvert, in xvimagesink, or in both. However, I can't use >>> fbdevsink because it interferes with X11, trying both of them to >>> "take control" of the framebuffer. Any hint about what can I try to >>> find out what's failing and how to solve it? >> It's more likely a bug in XV driver. Make sure you use the very latest >> upstream code there. >> >>> Also, I have another problem. Only one of every 7 buffers seems to be >>> updated with a new frame, the other 6 remains with the first fame >>> they captured at the beginning, so I have a video of the same >>> sequence of 6 frames repeating all time the same and one single frame >>> that seems to be correct between each 6 frames sequence. >> Looks familiar, but something that would have been fixed a long time >> ago. Which GStreamer version are you running ? >> >> Nicolas >> > _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
Free forum by Nabble | Edit this page |